Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@openjpa.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <49A2D149.90400@apache.org>
Date: Mon, 23 Feb 2009 11:39:37 -0500
From: David Ezzio <dezzio@apache.org>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: users@openjpa.apache.org
Subject: Re: Is the implementation of lock(LockModeType.READ) correct?
References: <498A2E95.2060208@oracle.com> <498B8D8A.9090507@oracle.com>
 <1233929408156-2284285.post@n2.nabble.com>
 <1233931028441-2284440.post@n2.nabble.com>
 <1233932854356-2284592.post@n2.nabble.com>
 <1233935253381-2284778.post@n2.nabble.com> <498D966C.1060108@apache.org>
 <1234023251328-2289651.post@n2.nabble.com> <498EDEFB.8060705@apache.org>
 <1234169842895-2296335.post@n2.nabble.com> <49905BF0.7010304@apache.org>
 <1234200650643-2298432.post@n2.nabble.com> <499214FB.9090705@apache.org>
 <1234689924787-2329205.post@n2.nabble.com> <499AC058.8030900@apache.org>
 <1235003259426-2350288.post@n2.nabble.com> <49A0443D.80900@apache.org>
 <1235241209689-2364702.post@n2.nabble.com>
In-Reply-To: <1235241209689-2364702.post@n2.nabble.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.
>>
> 
>