Return-Path: 
 <users-return-3705-apmail-openjpa-users-archive=openjpa.apache.org@openjpa.apache.org>
Delivered-To: apmail-openjpa-users-archive@minotaur.apache.org
Received: (qmail 1573 invoked from network); 16 Feb 2009 14:11:20 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 16 Feb 2009 14:11:20 -0000
Received: (qmail 74009 invoked by uid 500); 16 Feb 2009 14:11:20 -0000
Delivered-To: apmail-openjpa-users-archive@openjpa.apache.org
Received: (qmail 73981 invoked by uid 500); 16 Feb 2009 14:11:20 -0000
Mailing-List: contact users-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:users-help@openjpa.apache.org>
List-Unsubscribe: <mailto:users-unsubscribe@openjpa.apache.org>
List-Post: <mailto:users@openjpa.apache.org>
List-Id: <users.openjpa.apache.org>
Reply-To: users@openjpa.apache.org
Delivered-To: mailing list users@openjpa.apache.org
Received: (qmail 73970 invoked by uid 99); 16 Feb 2009 14:11:20 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2009 06:11:20 -0800
X-ASF-Spam-Status: No, hits=0.2 required=10.0
	tests=SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of
 lists+1214986160035-208411@n2.nabble.com designates 216.139.236.158 as
 permitted sender)
Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158)
    by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2009 14:11:11 +0000
Received: from tervel.nabble.com ([192.168.236.150])
	by kuber.nabble.com with esmtp (Exim 4.63)
	(envelope-from <lists+1214986160035-208411@n2.nabble.com>)
	id 1LZ4BN-000537-NT
	for users@openjpa.apache.org; Mon, 16 Feb 2009 06:10:49 -0800
Message-ID: <1234793449721-2334993.post@n2.nabble.com>
Date: Mon, 16 Feb 2009 06:10:49 -0800 (PST)
From: Pinaki Poddar <ppoddar@apache.org>
To: users@openjpa.apache.org
Subject: Re: Is the implementation of lock(LockModeType.READ) correct?
In-Reply-To: <1234771383249-2333637.post@n2.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Nabble-From: ppoddar@apache.org
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>
 <1234723851620-2330901.post@n2.nabble.com>
 <1234771383249-2333637.post@n2.nabble.com>
X-Virus-Checked: Checked by ClamAV on apache.org


Hi Philip,
The flag exists and its documentation/naming indicates that it should do
what you are asking for. And you are right that it is set to true for
VersionLockManager -- which is the default for optimistic transactions. But
I see no other part of the code is making use of this flag. More
investigation is required. But as I am busy with some performance
enhancement drug (oops, work;) for OpenJPA I am not being able to pay enough
attention to this thread.
 

Philip Aston wrote:
> 
> Thanks Pinaki,
> 
> Are you sure? Setting:
> 
>       <property name="openjpa.LockManager"
> value="version(VersionCheckOnReadLock=true)"/>
> 
> doesn't change the behavior of my case, and AFAICS from the code "true" is
> the default for VersionCheckOnReadLock with the version lock manager.
> 
> - Phil
> 
> 
> Pinaki Poddar wrote:
>> 
>> Philip,
>>>  do the optimistic lock checks for read locks after the INSERT, DELETE,
>>> and UPDATES for the transaction.
>>   This is currently possible with setting VersionCheckOnReadLock property
>> on LockManager.
>> I think this will ensure that all three Flags become part of commit set
>> and thus the transactional consistent extends to consistency of the
>> entire dataset that the test case is demanding.
>> 
>> Pinaki
>>  
>> 
>> 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
>>> 
>>> 
>>> 
>>> dezzio wrote:
>>>> 
>>>> Hi Philip,
>>>> 
>>>> But why does EclipseLink pass the test?
>>>> 
>>>> Clearly the implementation could use SELECT FOR UPDATE when it checks 
>>>> the READ lock's state prior to commit.  If it did that, then both 
>>>> transactions would not succeed, and in fact, due to the likelihood of 
>>>> deadlock in our example case, they both might fail.
>>>> 
>>>> These kind of issues do not get sorted by argument.  They are settled
>>>> by 
>>>> test cases in the TCK.  For this issue, there is no TCK test case, and 
>>>> thus, ipso facto, OpenJPA complies with the spec.  You can still argue 
>>>> that it doesn't comply with the spec in the best way, and you may be 
>>>> right.  I could be persuaded by understanding the behavior of competing 
>>>> implementations.
>>>> 
>>>> Cheers,
>>>> 
>>>> David
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/Is-the-implementation-of-lock%28LockModeType.READ%29-correct--tp2272546p2334993.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.