[hibernate-dev] JPA2 locking

Emmanuel Bernard emmanuel at hibernate.org
Thu Oct 22 05:51:12 EDT 2009

It seems to be the RR definition to me
"All data records read by a SELECT statement cannot be changed;"

On 20 oct. 09, at 18:16, Steve Ebersole wrote:

> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

More information about the hibernate-dev mailing list