It's a new internal Connection, but it's running on the same internal
Session, so it's running inside the context of the original transaction.
We do that to make sure that some bits of internal state don't
accidentally "pollute" the original Connection object.
You should not be getting a deadlock.
If you are, that is a bug somewhere.
Do you have a reproducible test-case?
Or at the very least a Java thread-stack-dump?
Also,
(a) what version are you running?
(b) what does your database URL look like?
On 2013-05-24 02:17, Gili wrote:
Hi,
Based on the third answer at
https://groups.google.com/forum/#!msg/h2-database/VoE3AU7mSuM/YAReMtnRsZQJ
<https://groups.google.com/forum/#%21msg/h2-database/VoE3AU7mSuM/YAReMtnRsZQJ> I
am expecting a AFTER DELETE Trigger to get the same Connection as the
statement that executed the DELETE operation, but it does not. I am
seeing two separate connections and if they attempt to write to the
same table the operation deadlocks.
Did this behavior change since June 2010 (when linked post was made)?
Are trigger supposed to get the same connection as the original
operation? If not, is it possible to configure them to do so?
I ask because I'm still trying to solve this
question: http://stackoverflow.com/q/16705097/14731
--
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 h2-database+unsubscr...@googlegroups.com.
To post to this group, send email to h2-database@googlegroups.com.
Visit this group at http://groups.google.com/group/h2-database?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
