[hibernate-dev] JPA2 locking

[Emmanuel Bernard]

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).