Re: [jbosscache-dev] READ_COMMITTED should be enforced for Hibernate 2nd level caching?
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.
Cheers
--
Manik Surtani
Lead, JBoss Cache
http://www.jbosscache.org
manik(a)jboss.org
Attachments:
- attachment.html (text/html — 3.9 KB)