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