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

[Brian Stansberry]

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

Good; glad that's still there and it's not just using the 
presence/absence of the node to decide to abort.

I think

get(k)
put(k, v2)
pfer(k, v1)

is a miswritten application. The point of pfer is to cache data that's 
just been read from a external store that's the truth of the system. A 
threat that stores a modified version and then reads the true version 
and tries to store it is a misuse.

It would be cool to have the transaction context updated with the pfer 
value but I don't think it's a real world need.

My thinking on this is colored by the fact that pfer was designed for 
use in a second level cache, i.e. there is a first level cache that 
provides the R_R semantic to the application. Without the first level 
cache the presence of the null value in the tx context from the initial 
get() is for sure a problem.


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com