[hibernate-dev] JPA2 locking

[Steve Ebersole]

But my point is that the spec is misusing the term repeatable read here.
Repeatable read in database terms is strictly about making sure a
transaction sees the the same data "version" every time it reads a given
row.  That has nothing *necessarily* to do with blocking concurrent
writers.  In fact MVCC is all about actually *allowing* those concurrent
writers in this exact situation; and in fact in classic MVCC T@ (the
concurrent writer) will be allowed to continue and even succeed; it is
T1 that will fail later if it tries to write to that row.  This is
clearly what the spec is saying should not be allowed to happen.  

My reading of those PESSIMISTIC_* mode rules is that we need to make
sure T2 blocks or fails as soon as it tries to get its write lock.  Now
on MVCC in practice does an intention lock (select ... for update, et
al) achieve that?  Or doe we explicitly need to grab a, exclusive/write
lock from T1?  That part I am not sure.


On Thu, 2009-10-22 at 11:51 +0200, Emmanuel Bernard wrote:
> It seems to be the RR definition to me
> http://en.wikipedia.org/wiki/Isolation_(database_systems)#REPEATABLE_READ
> "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
> 
-- 
Steve Ebersole <steve at hibernate.org>
Hibernate.org