Hi, > Does H2 issue one stack-trace per deadlocks?
H2 throws an exception on one of the connections, to solve the problem. > Does the exception message list the tables in the order in which they were locked? I'm not sure, I think yes. See the source code of RegularTable.getDeadlockDetails and Session.locks for details. But this might change in the future. > 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 Yes. Java for example avoids this problem by not allowing you to upgrade a lock from shared to exclusive. But database in general allow it. Regards, Thomas On Wed, Jun 19, 2013 at 10:12 PM, cowwoc <[email protected]> wrote: > 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. > > > -- 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.
