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--tp2272546p2284592.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
