db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen <Oystein.Grov...@Sun.COM>
Subject Re: Derby, identity columns & locks on syscolumns
Date Mon, 03 Mar 2008 10:37:22 GMT
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

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.


View raw message