Problem solved.
One of our applications left a transaction uncommitted and that
connection was not closed either.
So it just held some read locks on tables.
Thus preventing (as it should) the update operations on those tables (in
other words exclusive or write locks).
It seems that if transaction has some locks but is doing nothing for a
long time then it is "killed" after a long period of time
in non-multithreaded mode and not at all in multithreaded mode.
These assertions are tentative and meant partly as a question to you
Thomas, if the case really is so.
This issue brought the idea of a feature request.
It would be great if INFORMATION_SCHEMA would have a table called
TRANSACTIONS
that would list all currently open transactions. That table would help
identifying the kind of problems I had.
It is particularly useful in an environment where many different people
develop applications on your database.
- rami
8.8.2010 10:06, Thomas Mueller kirjoitti:
Hi,
It would be very nice to have a simple, standalone test case for this
problem. Maybe there is a concurrency problem with unlocking when
using the multi-threaded option, but without test case it's hard to
tell. Unfortunately I don't have time to write a test case right now.
I will have time in about one week.
Regards,
Thomas
On Friday, August 6, 2010, Rami Ojares<rami.oja...@gmail.com> wrote:
On 5.8.2010 10:15, Thomas Mueller wrote:
Hi,
Like most settings, you can add it to the database URL:
;LOCK_TIMEOUT=10000. to find out which connection is holding the lock,
see INFORMATION_SCHEMA.LOCKS.
Thanks,
Now I know that sometimes some operations leave tables locked (there might be
even 20 tables locked at some point)
And while those locks are kept update operations fail.
When I had MULTI_THREADED on those locks were never released.
But now that I turned MULTI_THREADED off those locks are released at some point.
I don't know exactly how long they are kept but it seems that some tables stay
locked longer than others.
So the follow up question is how should I proceed with the debugging.
Eg. How can I find out exactly what operations caused the locks?
What could cause locks to linger (for maybe 10-30 minutes) in the first place?
- rami
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to h2-datab...@googlegroups.com.
To unsubscribe from this group, send email to
h2-database+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to h2-datab...@googlegroups.com.
To unsubscribe from this group, send email to
h2-database+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
