All understood and agreed. The problem is not 1., and I'm using read committed. The problem is in the implementation of the VersionLockManager itself. It does the check, then leaves a gap where the data can be modified by a separate commit before the update happens. Thus its actual behaviour is "verifying that the version of all read-locked instances is unchanged at the start of the commit of the transaction".
Pinaki Poddar wrote: > > Hi Philip, > I did not execute the test case but reading it gave me the impression > that it is exercising/exposing the following known limitation. But may be > I should analyze the test case deeper to understand what is causing this > behavior. > > 1. "In order to maintain reasonable performance levels when loading object > state, OpenJPA can only guarantee that an object is locked at the proper > lock level after the state has been retrieved from the database. This > means that it is technically possible for another transaction to "sneak > in" and modify the database record after OpenJPA retrieves the state, but > before it locks the object. The only way to positively guarantee that the > object is locked and has the most recent state to refresh the object after > locking it." > > 2. On VersionLockManager (which is the default and being used in this > case): "This lock manager does not perform any exclusive locking, but > instead ensures read consistency by verifying that the version of all > read-locked instances is unchanged at the end of the transaction." > > 3. Another possibly relevant point: "In order for the version lock > manager to prevent the dirty read phenomenon, the underlying data store's > transaction isolation level must be set to the equivalent of "read > committed" or higher." > > > > Philip Aston wrote: >> >> Thanks Pinaki. >> >> I don't think the documented known issues cover my case. The first bullet >> point is about the pessimistic lock manager, which I'm not using. The >> second bullet is about the read consistency of the locked object - this >> isn't the problem either. The last paragraph is again about the >> pessimistic lock manager. And I don't see any of the INFO level messages >> referred to. >> >> I find the documented issues to be reasonable, but I'm afraid I can't say >> the same of the read locking implementation. >> >> - Phil >> >> >> Pinaki Poddar wrote: >>> >>> Hi Philip, >>> The points you raise are valid, correct and known. Please refer to >>> [1]. >>> >>> By the way, the test case is very neat! >>> >>> [1] >>> http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_locking_issues >>> >>> >>> >> >> > > -- View this message in context: http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2284778.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
