Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 03 Mar 2008 11:37:22 +0100
From: =?ISO-8859-1?Q?=D8ystein_Gr=F8vlen?= <Oystein.Grovlen@Sun.COM>
Subject: Re: Derby, identity columns & locks on syscolumns
In-reply-to: 
 <882C3355DFF9D3468379DD1E8C115FC713BE48714A@EVS-RED.coloflorida.com>
Sender: Oystein.Grovlen@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <47CBD4E2.6060703@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 8BIT
References: 
 <882C3355DFF9D3468379DD1E8C115FC713BE48714A@EVS-RED.coloflorida.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20071119)

Andrew Lawrenson wrote:
> I've done some more experimentation & testing.
> 
> At the moment, when syscolumns is updated, if a sub-transction is done, the update is done with an expicit no-wait on locks.
> I've tried changing this so that it will use the same wait policy as the parent transaction - when this is done, I see none of the problems reported, and can have up to 100 concurrent threads inserting without any failing (whereas before this would instantly lock up).
> 
> So the question now is: "is the no-wait for the sub-transaction actually necessary?".
> 
> Personally, I can't see why it is, although I'm not exactly a guru at derby internals.  If the reason why is simply to increase concurrency, then I think it's flawed, as it forces more updates to be carried out by the parent transaction, which will hold the lock much longer before committing...
> 
> Any ideas?  Or is this the wrong list to be asking - should I pose this on derby-developers instead?
> 

I think derby-dev is more appropriate for this discussion.  I do not 
know why there is a no-wait for subtransactions, maybe it is done to 
avoid risks of deadlocks.  You could try running the Derby test suites 
to see if some problems are revealed.

-- 
�ystein