Have a look at this thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569 <http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569> Does it make sense to enforce READ_COMMITTED for the Hibernate 2nd Level Cache provider for JBC3, if MVCC is used?

Jason T. Greene wrote: > Manik Surtani wrote: >> Have a look at this thread: >> >> http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569 >> <http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218569> >> >> Does it make sense to enforce READ_COMMITTED for the Hibernate 2nd >> Level Cache provider for JBC3, if MVCC is used? > > I would agree that REPEATABLE_READ does not make sense for a second > level cache. > The only logical use for R_R in the second level cache case is if someone uses the Hibernate Session.evict(Object) method to evict an entity or Session.clear() to clear all entities, and then later in the tx wishes to read the entity again. Otherwise the Session itself acts as a R_R cache. (This is covered on page 13 of http://www.jboss.org/file-access/default/members/jbossclustering/freezone....) > However, this sounds like a problem with PFER. If someone calls PFER, > I think the original transaction should resync the node snapshot. How would this be done? AFAIK the application has no control over the data in JBCs transaction context. In other > words, the application has already attempted to write a new value (in > the same thread and source tx even), so RR isolation is not only > unnecessary, it is inconsistent with expectations. >

> However, this sounds like a problem with PFER. If someone calls PFER, > I think the original transaction should resync the node snapshot. How would this be done? AFAIK the application has no control over the data in JBCs transaction context.

On 17 Mar 2009, at 20:33, Jason T. Greene wrote: > Brian Stansberry wrote: > >>> However, this sounds like a problem with PFER. If someone calls >>> PFER, I think the original transaction should resync the node snapshot. >> How would this be done? AFAIK the application has no control over the >> data in JBCs transaction context. > > The PFER implementation, not the application, would just drop the node > from the tx context which invoked pfer. That would mean that any > subsequent read would fetch the most current data. No, that is not correct. PFER suspends ongoing TXs and runs outside of any TX, to prevent a failure rolling back the TX. And this is the root of the problem.

On 18 Mar 2009, at 13:54, Jason T. Greene wrote: > Manik Surtani wrote: >> On 17 Mar 2009, at 20:33, Jason T. Greene wrote: >>> Brian Stansberry wrote: >>> >>>>> However, this sounds like a problem with PFER. If someone calls >>>>> PFER, I think the original transaction should resync the node >>>>> snapshot. >>>> How would this be done? AFAIK the application has no control over >>>> the data in JBCs transaction context. >>> >>> The PFER implementation, not the application, would just drop the >>> node from the tx context which invoked pfer. That would mean that >>> any subsequent read would fetch the most current data. >> No, that is not correct. PFER suspends ongoing TXs and runs outside >> of any TX, to prevent a failure rolling back the TX. And this is the >> root of the problem. > > "correctness" I think is in the eye of the beholder :) > > To me it does not seem correct that i can do > > pfer(k, 7) > get(k) == null The above would only happen if you did: tx.start() // ensure this in a transactional context assert get(k) == null // initially empty pfer(k, 7) // this *always* happens outside of the context of a tx assert get(k) == null // this still holds true since we initially read this as a null.

Anyway, this pattern has nothing to do with the problem at hand, or the correctness/consistency I discussed, which has to do with handling a remove() on a null entry with repeatable read.

On 18 Mar 2009, at 14:07, Jason T. Greene wrote: > Manik Surtani wrote: >> On 18 Mar 2009, at 13:54, Jason T. Greene wrote: >>> Manik Surtani wrote: >>>> On 17 Mar 2009, at 20:33, Jason T. Greene wrote: >>>>> Brian Stansberry wrote: >>>>> >>>>>>> However, this sounds like a problem with PFER. If someone calls >>>>>>> PFER, I think the original transaction should resync the node >>>>>>> snapshot. >>>>>> How would this be done? AFAIK the application has no control over >>>>>> the data in JBCs transaction context. >>>>> >>>>> The PFER implementation, not the application, would just drop the >>>>> node from the tx context which invoked pfer. That would mean that >>>>> any subsequent read would fetch the most current data. >>>> No, that is not correct. PFER suspends ongoing TXs and runs >>>> outside of any TX, to prevent a failure rolling back the TX. And >>>> this is the root of the problem. >>> >>> "correctness" I think is in the eye of the beholder :) >>> >>> To me it does not seem correct that i can do >>> >>> pfer(k, 7) >>> get(k) == null >> The above would only happen if you did: >> tx.start() // ensure this in a transactional context >> assert get(k) == null // initially empty >> pfer(k, 7) // this *always* happens outside of the context of a tx >> assert get(k) == null // this still holds true since we initially >> read this as a null. > > Yep And I would say that this is expected since pfer is clearly documented as an operation that happens outside of the current transactional context. Of course, we *could* hack it to provide more natural behaviour in *some* cases, by actually tracking any ongoing transaction, suspending it, completing the pfer, and if the pfer is successful remove any cached nodes in the *original* transaction's context so this is refreshed. But this will only work if the node has not been first modified by the transaction, otherwise you will end up either losing changes made by the transaction, or flushing transaction changes prematurely. E..g., this case: get(fqn, k) == null put(fqn, k1, 1) pfer(fqn, k2, 2) If we only deal with some cases (node not modified before pfer) and not others, that would lead to even more confusion in what is and is not expected behaviour. :-)

On 18 Mar 2009, at 14:24, Jason T. Greene wrote: > Interesting scenario. Put() would acquire the lock, and then the pfer > would block forever. Very weird. Well, pfer has a 0ms lock acquisition timeout so it would be a no-op.