Hi Philip,
Yup, I agree with your argument, and it seems to me the conclusion shows
that our example (either mine or the original one that you proposed and
I expanded) doesn't really mirror what a bank would do. If it dispensed
175, it would likely zero out all three balances meaning that not one of
our examples (original without reordering, original with reordering, or
my latest one) would allow both transactions to succeed.
Since this is the reasonable conclusion, that leads me back to the need
for a use case that actually requires the functionality that you seek
(an optimistic read lock that holds for the entire transaction.)
Cheers,
David
Philip Aston wrote:
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.
