[
https://issues.apache.org/jira/browse/DERBY-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12508349
]
Knut Anders Hatlen commented on DERBY-2689:
-------------------------------------------
> For 1, there seems to be no synchronization at all in this class.
Yes, you're absolutely right. For some reason I kept thinking that it was
shared between threads, but lcc is not.
> As far as 2 goes-- if we set "unusedActs" to false at the beginning of the
> loop and while trying to close all activations, get an exception won't we end
> up with the case where unusedActs = false, yet there are unused activations
> which the loop did not get to?
I think you are right. We risk ending up with an incorrect value no matter
where we put the assignment. Since it's really just a hint as to when it could
be worthwhile to do the cleanup, I don't think it really matters. If we are
leaking activations, the cleanup code will be triggered sooner or later, but
there might be more than 20 activations (which is a low number anyway).
> On the same note, I'm not sure I understand why we have to do the following:
>
> for (int i = acts.size() - 1; i >= 0; i--) {
>
> // it maybe the case that a reset() ends up closing
> // one or more activation leaving our index beyond
> // the end of the array
> if (i >= acts.size())
> continue;
BaseActivation.close(), which is called further down in the method, calls
lcc.removeActivation() which removes only one activation and should therefore
not cause any problems. I assume that the reset() method mentioned in the
comment is BaseActivation.reset(), but I can't see that it will close any
activations, so I believe you are right on this too. Perhaps the comment refers
to some old code?
> Deadlock with GenericPreparedStatement
> --------------------------------------
>
> Key: DERBY-2689
> URL: https://issues.apache.org/jira/browse/DERBY-2689
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.2.2.0
> Environment: Windows
> Reporter: Marc Ewert
> Assignee: Manish Khettry
> Priority: Critical
> Attachments: deadlock.patch.txt, TestDerbyPreparedStatements.java
>
>
> We encountered two times a deadlock inside of derby. It seems that we can't
> workaround it. The involved two threads are attached, it looks like a
> classical deadlock:
> "Thread-22" daemon prio=6 tid=0x0cdaa400 nid=0x1c0 waiting for monitor entry
> [0x1317f000..0x1317fd4c]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown
> Source)
> - waiting to lock <0x052f4d70> (a
> org.apache.derby.impl.sql.GenericPreparedStatement)
> at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown
> Source)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown
> Source)
> at
> org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
> Source)
> at
> org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericActivationHolder.<init>(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown
> Source)
> - locked <0x05306f88> (a
> org.apache.derby.impl.sql.GenericPreparedStatement)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown
> Source)
> at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source)
> - locked <0x047beb00> (a org.apache.derby.impl.jdbc.EmbedConnection40)
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source)
> [custom methods]
> "ThreadPoolThread-SyncScheduler-3-1" prio=2 tid=0x0e620400 nid=0xfec waiting
> for monitor entry [0x10a7e000..0x10a7fa14]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at org.apache.derby.impl.sql.GenericPreparedStatement.finish(Unknown
> Source)
> - waiting to lock <0x05306f88> (a
> org.apache.derby.impl.sql.GenericPreparedStatement)
> at org.apache.derby.impl.sql.execute.BaseActivation.close(Unknown
> Source)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.addActivation(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.BaseActivation.initFromContext(Unknown
> Source)
> at
> org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown
> Source)
> at
> org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown
> Source)
> at org.apache.derby.impl.sql.GenericActivationHolder.<init>(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown
> Source)
> - locked <0x052f4d70> (a
> org.apache.derby.impl.sql.GenericPreparedStatement)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown
> Source)
> at org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source)
> - locked <0x04225178> (a org.apache.derby.impl.jdbc.EmbedConnection40)
> at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown
> Source)
> [custom methods]
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
