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
