Good points! But they raise a few questions that have been lying dormant inside of me.

The relationship between a connection and transaction.

Can I have 2 different connections that participate in the same transaction?
My current understanding tells me that a transaction is the private property of a connection.

So if 2 connections belong always to 2 separate transactions then it follows that if I would use the connection stored in the trigger instance in the remove() method it would not participate in the drop trigger transaction and thus even if I would
throw an exception the drop trigger would succeed.

So what about the connection provided to the fire method.
Is that connection the same connection that did some action to the table
and thus caused the trigger to fire. To me it seems that this connection belongs to the same transaction that caused the trigger to fire. And it follows that trigger should not commit that transaction because the decision to commit should come from the user (not the trigger). The documentation makes this also clear

> Committing or rolling back a transaction within a trigger is not allowed, except for SELECT triggers.

But what happens if I do commit. For example if I create a table or some other object it has a side
effect of committing a transaction.

> Why don't you keep the connection that was given to the trigger in the 'init' method?

That´s a good idea. But whose privileges does that connection have?

- rami

On 4.6.2010 0:21, Thomas Mueller wrote:
There is some kind of deadlock, but not a "Java level deadlock"
because you try to connect over TCP/IP. Why don't you connect in
embedded mode? I'm not saying this will work, but why do you use
TCP/IP to connect to a database within the same VM?

Why don't you keep the connection that was given to the trigger in the
'init' method?


--
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.

Reply via email to