If you really want to do this, then you are going to have to invoke the cleanup code from some sort of timer that you initiate in the drop trigger. That way, the cleanup work is done after the drop trigger code is done and released its locks.
I don't know exactly what you are doing, but opening a connection to the db engine from inside the db engine process is not something I'd ever expect to work. My naive answer to your problem would be that you need to write your cleanup code in SQL and run it as part of the drop trigger statement rather than trying to open another connection to do it. 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.
