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