Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <430A2D79.6070805@sbcglobal.net>
Date: Mon, 22 Aug 2005 12:54:33 -0700
From: Mike Matrigali <mikem_app@sbcglobal.net>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Derby 213 patch
References: <668806853.1123767650948.JavaMail.jira@ajax.apache.org>
 <43038278.8000102@sbcglobal.net> <430A0B46.6020608@acadiau.ca>
 <430A22BD.4070509@acadiau.ca>
In-Reply-To: <430A22BD.4070509@acadiau.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

A method that does not require looking at a lock table, it instead
to test directly the behavior of what is locked.  It will require
2 connections (not 2 threads), so very easy to do in java/jdbc.
Something like:
o set serializable
o execute select statement in thread one
o try to update same row in thread 2, if thread one committed then
   update will succeed, if not then lock will time out.
To make test run faster, set default lock timeout to something small
like 1 second.

Be careful about depending on anything about XID's, as they are
implementation specific.  As you have seen they can be reused, they
may jump by more than one depending on timing (background threads
may use xacts also), and they may not change at all for read only
transactions.

Philip Wilder wrote:
>>
>>
>>> I don't think it is  so good to have  references to internal classes
>>> (e.g org.apache.derby.client.am.ResultSet) in the functional tests.
>>> Is there a  way within the public API to test if autocommit has
>>> occurred, maybe the current XID from the lock table VTI would help.
>>>  
>>>
>> Initial investigations don't yield anything useful from the LockTable. 
>> It would seem that for the client ResultSet a lock, identical in all 
>> ways except for the final digit in the XID, is held both before and 
>> after the auto commit. This differs from the embedded behavior where 
>> attempting to access the lock table tells me that there are never any 
>> locks held for my tests. I'll continue investigating but if someone 
>> can prove me wrong and show how the lock table can be useful in this 
>> regard or offer me an alternate solution I'd be most appreciative. 
> 
> 
> 
> Sorry Kathey, I'm being dim. XIDs have the potential to work they just 
> require a little more creativity then my previous solution. Testing 
> seems to indicate that XIDs aren't held over a commit. Ergo if I compare 
> the XID before the commit with any XIDs after the commit and have a 
> match I have criteria for failing the test.
> 
> Philip
> 
>