If you really want to get into the dirty details cause the situation to happen, then attach gdb (on *unix-like platforms) to your jvm process look at the states of the threads. YOu could also use a profiling tool to take a snapshot of all the threads in the jvm process to see who is blocking what.
As a general statement, the purpose of a mutex is to SERIALIZE access to a resource. If your drop trigger statement has a lock on the database or the meta data table or some other component that means all other threads will be on hold until your drop trigger statement is done. If you are doing something that stops the drop trigger statement from completing, then the lock it is holding will never get released and no other threads will be able to proceed. On May 29, 2010, at 1:59 AM, Rami Ojares wrote: > You are right James. > So let's study my situation a bit closer instead of generically. > > In my case a drop trigger statement is executing. > During this execution a new connection comes to the server. > Granted the other end of that connection belongs to the same jvm and blocks > the execution of drop trigger statement. > > Question #1: Why is the connection not accepted? > This would mean that no new connections can be created while a drop trigger > statement is running which would sound bizarre. > > Question #2: If the connection would be created why can't a delete statement > in another connection go through while drop trigger is blocking? > As drop trigger statement keeps waiting my cleanup statements would be > finished and thus let drop trigger finish also. > > Personally I find threads to be sometimes magical. > I quess I am old fashioned in that way ;-) > > - rami > > On 29.5.2010 7:49, James Gregurich wrote: >> threads are not magical. code has to be crafted to work correctly in >> concurrent mannger. take a look at the H2 source code. it has mutexes in >> many places (search for the "synchronized" keyword in the source). So if >> you have a thread that locks a mutex then causes another thread to hit that >> same mutex, then deadlock is exactly what you'll get. >> >> On May 28, 2010, at 1:20 AM, Rami Ojares wrote: >> >> >>> Excuse me, but that sounds silly. >>> Threads have been invented! >>> One thread is the client, listening daemon opens a new server thread and so >>> on. >>> Why do you think a very clever design is needed? >>> >>> - rami >>> >>> On 28.5.2010 9:54, James Gregurich wrote: >>> >>>> if you have the db engine connect to itself while processing a query, >>>> deadlock is what I would expect to happen. It would take a very clever >>>> design to allow the db engine to recursively call itself without >>>> deadlocking. >>>> >>>> On May 27, 2010, at 1:58 AM, Rami Ojares wrote: >>>> >>>> >>>> >>>>> >>>>> >>>>>> umm. are you asking the db engine to connect to itself from inside a >>>>>> trigger? >>>>>> >>>>>> >>>>> I am trying to do additional cleanup whenever a trigger is removed. >>>>> I can not cleanup if I don't have a connection to the database. >>>>> So yes. >>>>> >>>>> - rami >>>>> >>>>> >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "H2 Database" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/h2-database?hl=en.
