> Gili, could you comment on my exact initial example
> and confirm it is a dirty-read at cache level. See my
> above -3 comment. In my example there is nothing
> preventing T2 to commit, although it used a value
> updated by T1 that maybe is never commited by T1.
> T1's lock() call is useless in this case, it takes
> place after T2's commit (i don't event know if
> calling lock() before T2's commit would change
> anything too - see my guess number 2 at the end of my
> first post). Thanks.
I believe you're assuming a transaction isolation level that allows dirty reads. As I've stated, the default isolation level (READ_COMMITTED) doesn't allow this to begin with so you have little to worry about.
Assuming you *are* using a lower isolation level then yes I would agree your example shows a potential dirty read. As I've stated above, I'm not sure how *any* JPA implementation would prevent this from taking place given the current API. It's not clear whether the specification was assuming READ_COMMITTED, some mistake was made or maybe they know of an implementation technique I do not. In any case, I've asked James from EclipseLink to comment on your post. I'll defer to his expertise on this one.
[Message sent by forum member 'cowwoc' (cowwoc)]
http://forums.java.net/jive/thread.jspa?messageID=315852