Oh yeah - my bad. Try this one instead: Suppose there are a set of Accounts, and a business rule that says that the net balance must be positive.
Innocent wants to draw down on Account 1 as far as possible. It read locks the of Accounts, sums up the value, and and subtracts the positive total from Account 1. Innocent begins its commit, and its read locks are validated. Meanwhile InnocentToo does the same for Account 2, and commits. Innocent updates Account 1 and finishes its commit. The total in account summary is now negative, violating the business rule. If read locks worked as I think they should, Innocent would have received an OptimisticLockException. dezzio wrote: > > Hi Philip, > > When two transactions read the same version of AccountSummary, both > cannot successfully update its sum. Only one will successfully commit. > > David > > -- View this message in context: http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2296335.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
