[
https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175216#comment-13175216
]
Kathey Marsden commented on DERBY-5552:
---------------------------------------
Yes, definitely you want your test to be the new Junit style so that is the
place to look.
I think I have solved the mystery of the missing XA client traces and filed
DERBY-5553 for that issue.
I am trying to think of a scenario where we we execute a valid statement would
get a lock timeout and then at the time of processing the exception the
statement would have become invalid. One reason for a statement becoming
invalid would be for instance if a table had been altered, for example if we
had a prepared statement "SELECT * FROM TAB" and then a column was added or
dropped. In that scenario the statement would be recompiled long before the
lock timeout occurred. If the problem statement is the one with the lock
timeout it would seem to be:
SELECT DISTINCT t3.ID, t3.OPLOCK FROM PKG_9145E10G.PLPM_PAIR t3,
PKG_9145E10G.PLPM_CHASSIS_9145E10G_USER t2, CORE_V1.DEVICE_ENTITY_USER t1,
CORE_V1.DEVICE_ENTITY t0 WHERE ((t0.ID = CAST (? AS INTEGER )) AND
(((t2.PLPM_PAIR_ID = t3.ID) AND ((t2.ID = t1.ID) AND (t1.DTYPE =
'PlpmChassis9145E10GUser'))) AND (t0.ID = t1.DEVICE_ENTITY_ID))) with 1
parameters begin parameter #1: 249360 :end parameter
ERROR 40XL2: A lock could not be obtained within the time requested. The
lockTable dump is:
Thu Dec 22 07:03:07 PST 2011
I am not sure how that could have gone invalid between the initial execution
and the lock time out.
> Derby threads hanging when using ClientXADataSource and a deadlock or lock
> timeout occurs
> -----------------------------------------------------------------------------------------
>
> Key: DERBY-5552
> URL: https://issues.apache.org/jira/browse/DERBY-5552
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.1.2
> Environment: Solaris 10, Glassfish V2.1.1,
> Reporter: Brett Bergquist
> Priority: Blocker
> Attachments: appserverstack.txt, client.tar.Z, derby.log,
> derbystackatshutdown.txt, execute.patch, transactionsleft.txt
>
>
> The issue arrives when multiple XA transactions are done in parallel and
> there is either a lock timeout or a lock deadlock detected. When this
> happens the connection is leaked in the Glassfish connection pool and the
> client thread hangs in
> "org.apache.derby.client.netReply.fill(Reply.java:172)".
> Shutting down the app server fails because the thread has a lock in
> "org.apache.derby.client.net.NetConnection40" and another task is calling
> "org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214)"
> which is waiting for the lock.
> Killing the appsever using "kill" and then attempting to shutdown Derby
> network server causes the Network Server to hang. One of the threads hangs
> waiting for a lock at
> "org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525)"
> and the "main" thread has this locked at
> "org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242)"
> and it itself is waiting for a lock which belongs to a thread that is stuck
> at
> "org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118)
> which is in the TIMED_WAITING state.
> Only by killing the Network Server using "kill" is possible at this point.
> There are transactions left even though all clients have been removed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
