On 10/20/2009 12:16 PM, 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. >
I guess we get into how repeatable read isolation level is implemented and whether it could be implemented without at least a read lock on the database table row. Or did you mean something else? I'm fine with requiring at least a database read lock (if everyone is happy with that). > > 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). >> >> >> >> _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
