Thanks for the attention so far Pinaki. I'm convinced the read lock behaviour is wrong, and I've said more than enough about it here if you come back to it after painting those go-faster stripes.
Regards, - Phil Pinaki Poddar (via Nabble) wrote: > Hi Philip, > The flag exists and its documentation/naming indicates that it should do > what you are asking for. And you are right that it is set to true for > VersionLockManager -- which is the default for optimistic transactions. > But I see no other part of the code is making use of this flag. More > investigation is required. But as I am busy with some performance > enhancement drug (oops, work;) for OpenJPA I am not being able to pay > enough attention to this thread. > > > Thanks Pinaki, > > Are you sure? Setting: > > <property name="openjpa.LockManager" > value="version(VersionCheckOnReadLock=true)"/> > > doesn't change the behavior of my case, and AFAICS from the code "true" > is the default for VersionCheckOnReadLock with the version lock manager. > > - Phil > > > Philip, >> do the optimistic lock checks for read locks after the INSERT, > DELETE, and UPDATES for the transaction. > This is currently possible with setting VersionCheckOnReadLock > property on LockManager. > I think this will ensure that all three Flags become part of commit set > and thus the transactional consistent extends to consistency of the > entire dataset that the test case is demanding. > > Pinaki > > > Philip Aston wrote: > Hi David, > > EL does an update for each read lock at commit time, setting its > version column to the same value. See my other post - I agree that > SELECT FOR UPDATE is not appropriate for read locks, and I instead > suggest a third approach; that is to do the optimistic lock checks > for read locks after the INSERT, DELETE, and UPDATES for the > transaction. > > - Phil > > > dezzio wrote: > Hi Philip, > > But why does EclipseLink pass the test? > > Clearly the implementation could use SELECT FOR UPDATE when it > checks > the READ lock's state prior to commit. If it did that, then both > transactions would not succeed, and in fact, due to the > likelihood of > deadlock in our example case, they both might fail. > > These kind of issues do not get sorted by argument. They are > settled by > test cases in the TCK. For this issue, there is no TCK test > case, and > thus, ipso facto, OpenJPA complies with the spec. You can still > argue > that it doesn't comply with the spec in the best way, and you > may be > right. I could be persuaded by understanding the behavior of > competing > implementations. > > Cheers, > > David > > > > > ------------------------------------------------------------------------ > This email is a reply to your post @ > http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2334993.html > You can reply by email or by visting the link above. > -- View this message in context: http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2350307.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
