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).