[hibernate-dev] JPA2 locking

[Steve Ebersole]

See my reading of P2 though is more than just ensuring a repeatable
read.

If T1 does lock(entity, LockModeType.PESSIMISTIC_READ) we need to make
sure T2 cannot update or delete that row b4 T1 completes.  That's
blocking, not simply repeatable read.


On Tue, 2009-10-20 at 17:55 +0200, Emmanuel Bernard wrote:
> On 20 oct. 09, at 17:46, Steve Ebersole wrote:
> 
> > Just wanted to point out that "checking" the isolation level may not  
> > be
> > accurate.  HSQLDB, for example, lets you set any isolation you want  
> > and
> > dutifully reports it back even though it (used to, at least) only
> > supports READ UNCOMMITTED.  But, I personally think we need to just
> > assume that we are running in at least READ COMMITTED (HSQLDB in a
> > single user environment would behave as if READ COMMITTED).  READ
> > UNCOMMITTED has to be universally considered evil in real practice :)
> 
> I think the spec assumes Read committed isolation at minimum, so we  
> should be good.
> 
> >
> > WRT PESSIMISTIC_READ, it really comes down to the intent.  Is this
> > supposed to stop other writers from writing to the given data until we
> > are done with it?  Aka, would this be an intention lock (I intend to
> > update this data so don't let other writers in here right now)?  Or
> > merely a guarantee of repeatable read?
> 
> Here is the contract
> If transaction T1 calls lock(entity, LockModeType.PESSIMISTIC_READ) or  
> lock(entity, LockModeType.PESSIMISTIC_WRITE)on an object, the entity  
> manager must ensure that neither of the following phenomena can occur:
>    • P1 (Dirty read): Transaction T1 modifies a row. Another  
> transaction T2 then reads that row and obtains the modified value,  
> before T1 has committed or rolled back.
>    • P2 (Non-repeatable read): Transaction T1 reads a row. Another  
> transaction T2 then modifies or deletes that row, before T1 has  
> committed or rolled back.
> 
> Any such lock must be obtained immediately and retained until  
> transaction T1 completes (commits or rolls back).
> 
> 
> 
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org