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

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

I patched the files to look like this and am running my test setup now.  So far 
so good.  In fact I am not seeing the deadlocks or lock timeouts at all now.   
Not sure why but it is all running smoothly with these changes:


Index: BasicNoPutResultSetImpl.java
===================================================================
--- BasicNoPutResultSetImpl.java        (revision 1222480)
+++ BasicNoPutResultSetImpl.java        (working copy)
@@ -256,7 +256,9 @@
                        }
 
                } catch (StandardException se) {
-                       activation.checkStatementValidity();
+            if (se.report() != StandardException.REPORT_ALWAYS) {
+                activation.checkStatementValidity();
+            }
                        throw se;
                }
 
Index: DeleteResultSet.java
===================================================================
--- DeleteResultSet.java        (revision 1222480)
+++ DeleteResultSet.java        (working copy)
@@ -201,7 +201,9 @@
                        source.reopenCore();
                        }
                } catch (StandardException se) {
-                       activation.checkStatementValidity();
+            if (se.report() != se.REPORT_ALWAYS) {
+                       activation.checkStatementValidity();
+            }
                        throw se;
 
                }
Index: RowChangerImpl.java
===================================================================
--- RowChangerImpl.java (revision 1222480)
+++ RowChangerImpl.java (working copy)
@@ -372,7 +372,7 @@
                }
 
                } catch (StandardException se) {
-                       if (activation != null)
+                       if (se.report() != StandardException.REPORT_ALWAYS && 
activation != null)
                                activation.checkStatementValidity();
                        throw se;
                }

                
> 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

        

Reply via email to