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.
Philip Aston wrote: > > 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 > > > Pinaki Poddar wrote: >> >> 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 >>>> >>>> >>> >>> >> >> > > -- View this message in context: http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2334993.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
