No, I don't agree. You could re-order these transactions so they didn't overlap with the same result. That is, I1 could complete Tx1, before I2 begins Tx2.
The Bank's rules on handling the joint account is flawed, and it essentially lets A&B overdraw the account by its current positive balance. For example, I1 could move all of the money to account B, then withdraw 175 from account A. Then I2 could withdraw the 175 from account B. - Phil dezzio (via Nabble) wrote: > Hi Philip, > > Actually, I was not thinking of proof by implementation, but > rather a mathematical proof. As it turns out, I think there > is a counter-example that disproves the viability of your > suggestion. > > It's an example that is only slightly different from the one > that we have discussed. > > For the same bank, assume that customer Innocent1 has three > accounts, A, B, and C, with balances of 100, 50, and 25. > Assume that Innocent2 shares account B jointly with Innocent1. > > Scenario: Innocent1 draws down account A by withdrawing 175. > At the same time Innocent2 draws down Account B by > withdrawing 50. Either transaction, by itself, satisfies the > bank's business rule that the total of a customer's accounts > cannot be less than zero. > > When the backend server executes the separate transactions, > the following time sequence of actions occurs on the JDBC > connections. > > Tx1 (for Innocent1) > begin tx > update A by setting balance to -75 > verify that B has not been modified (to satisfy read > lock held) > > Tx2 (for Innocent2) > begin tx > update B by setting balance to 0 > (does not block since the verify in Tx1 did not > obtain a pessimistic lock.) > commit tx > dispense 50 > > Tx1 > verify that C has not been modified (to satisfy read > lock held) > commit tx > dispense 175 > > Both succeed, and the read lock on B has not held until the > end of Tx1. > > Do you agree that this counter-example disproves your suggestion? > > Cheers, > > David > > > Philip Aston wrote: > >> Hi David, >> >> That would require studying openjpa internals in great depth, and I'm too >> time poor I'm afraid. >> >> >> dezzio wrote: >>> Hi Philip, >>> >>> Your suggestion might work. Would you like to create the proof? >>> >>> Cheers, >>> >>> David >>> >>> >>> 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 >> > > > ------------------------------------------------------------------------ > This email is a reply to your post @ > http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2364648.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--tp2272546p2364702.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
