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
