[jira] [Commented] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs

["Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13175022#comment-13175022 ] 

Brett Bergquist commented on DERBY-5552:
----------------------------------------

I found one problem.  In BasicNoPutResultImpl.java around line 250 is the code:

		try {
			LanguageConnectionContext lcc = getLanguageConnectionContext();
			if(lcc.getRunTimeStatisticsMode() && lcc.getXplainOnlyMode()) {
				// do nothing
			} else {
				openCore();
			}

		} catch (StandardException se) {
			activation.checkStatementValidity();
			throw se;
		}

For whatever reason (looks like something in my code), a lock timeout is being detected while executing in “openCore” and a StandardException is being thrown with SQLState “40XL2” and a report = 2 (REPORT_ALWAYS I Believe).  The exception is caught and then the 

	Activation.checkStatementValidity()

Is being called.  The statement appears not to be valid at that point and a new StandardExceptis thrown with SQLState.LANG_STATEMENT_NEEDS_RECOMPILE and report = REPORT_NEVER.  

The effect is that the Lock timeout exception is swallowed and the statement is recompiled and executed again.    This occurs over and over and the loop never ends.     This looks like the cause that the Network Server cannot shutdown in the bug.

It seems to me that if the exception being caught above is to be “REPORT_ALWAYS”, then the code should never check the statement validity and should just rethrow the original exception.


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