On 19/06/2013 3:44 PM, Noel Grandin wrote:
We don't lock rows, we lock tables, so that information would not be useful.
This kind of deadlock normally arises because different queries are
locking tables in different orders.
Okay that certainly simplifies things :) Let's tie some loose ends:
1. Does H2 issue one stack-trace per deadlocks? Or one per thread?
Meaning, was I seeing two separate deadlocks in my log or two errors
associated with a single deadlock? I'm guessing the former.
2. Does the exception message list the tables in the order in which
they were locked? Or does it just list a set of tables with an
indeterminate order?
3. Assuming my stack-trace is:
Session #5 (user: SA) is waiting to lock PUBLIC.PARTICIPANTS while
locking PUBLIC.COMPANIES (shared), PUBLIC.DEPARTMENTS (shared),
PUBLIC.CALLS (shared), PUBLIC.PARTICIPANTS (shared), PUBLIC.CONNECTIONS
(shared)."; SQL statement:
Session #6 (user: SA) is waiting to lock PUBLIC.PARTICIPANTS while
locking PUBLIC.COMPANIES (shared), PUBLIC.DEPARTMENTS (shared),
PUBLIC.CALLS (shared), PUBLIC.PARTICIPANTS (shared), PUBLIC.CONNECTIONS
(shared)."; SQL statement:
And assume that the method initially acquires a shared lock on a
participant, before upgrading to a write lock. So, let's see if I
understand this right...
Each thread looks up a separate participant but because H2 uses table
locks the two end up holding a shared lock on the entire table. Later on
they try to upgrade to a write lock only to discover that they have to
wait for the other thread to release the shared lock in order to do so.
Hence the deadlock. Makes sense?
Thanks,
Gili
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/h2-database.
For more options, visit https://groups.google.com/groups/opt_out.
