JBossDeveloper

Let's try and jot down what this method needs to perform. I'm calling it putFailFast() for now, but perhaps a different name (from 2.0.0) is better to avoid a mental conflict with the 1.x putFailFast() method which was a kludge.

From this thread, I see that this method needs to:

1) Suspend transactions so failures do not cause the tx to fail
2) Do not attempt to acquite write locks if pessimistically locked. Ignore version mismatch exceptions if optimistically locked.
3) 0 timeout on lock acquisitions
4) Replication (or invalidation, if used) forced to be asynchronous.
5) Exceptions suppressed.
6) Warnings logged at a much lower level than usual.

#3: Read locks, at very least, so this does not conflict with an update(). Otherwise, the put() may overwrite an update().

#5: To do with acquiring locks in 3, or replication exceptions to do with network issues.

Regarding #1, if we suspend the active transaction at cache put time, wouldn't JBC send cache changes too early (before the suspended + later resumed tx completes?)

Yes, but this is deemed acceptable since the cached versions are not deemed true representations of data (in this use case)

Manik: I think using a separate method is likely a cleaner approach. I do want to note
here that a separate method by itself can't solve the correctness issues I noted
in my comment of Sep. 18th, at least for the pessimistic case, since basically the
cache has no way of knowing whether the put() or the update() is providing newer
information. In the optimstic case with explicit versioning, the situation is better.

Scott: Are you wondering if we can get a "dirty read" if we call putFromExternalRead()
the transaction suspended? The assumption here is that the caller of
putFromExternalRead() only calls the method with data that was committed to the
database before the start of the outer transaction, and not with data that was updated
in the outer transaction. Hibernate, for example, makes that guarantee except in
the most exotic situations. (You might be able to fool it if you tried hard.)

Following up to my last comment: it may work pretty well to have "putFromExternalRead" simply never overwrite existing data.

When I've contrasted put() and update() I've been using the Hibernate cache terminology put() - cache fill (== putFromExternalRead()) - update - database change (== put()). I don't think a putFromExternalRead() would normally cause a "dirty read", but one possible interpretation of Scott's question was what would happen if you called putFromExternalRead() with data that wasn't yet committed to the database.

I don't know why the asynchronous replication of putFailFast() was added orginally, but my assumption is that it's about increasing concurrency and performance. Replicating cache fills synchronously doesn't increase correctness, so you might as well do it synchronously.

"otaylor" wrote:

I don't know why the asynchronous replication of putFailFast() was added orginally, but my assumption is that it's about increasing concurrency and performance. Replicating cache fills synchronously doesn't increase correctness, so you might as well do it synchronously.

"unless the current data is write locked" only works if you do have something like your Intention lock. (In my earlier post, I said "
I'd argue that get() needs to establish a hard read lock (even when the node isn't there, even if the isolation mode is READ_COMMITTED) that is upgraded to a write lock on put() and then released/downgraded afterwards.", so yes, I agree that it is one possible solution)

But I'd argue that replacing existing data on a putFromExternalRead() is never useful.

a) I check the cache and find nothing there
b) I read data from the database
c) I go to write my data back to the cache and find something there already already

Assuming that all database updates also cause cache updates, the data I find at step c) can't be older than the data I read at step b), so there is no point in replacing it.

The only thing that I'm aware of that the intention lock does better than "don't replace" is handle the case of entity deletion. (it might also work better in the case where we are invalidating across the cluster rather than replicating- I haven't thought through that situation thoroughly)