[jbosscache-dev] READ_COMMITTED should be enforced for Hibernate 2nd level caching?

[Jason T. Greene]

Manik Surtani wrote:
> 
> 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.  :-)

Interesting scenario. Put() would acquire the lock, and then the pfer 
would block forever. Very weird.

-- 
Jason T. Greene
JBoss, a division of Red Hat