[
https://issues.apache.org/jira/browse/DERBY-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-4053:
-----------------------------------
Attachment: DERBY4053_patch1_diff_July092009.txt
This patch DERBY4053_patch1_diff_July092009.txt is not yet intended for
checkin.
I thought this patch should fix the XA cleanup issue where we were not
differentiating between global XA vs local XA transaction and hence not roling
back local XA transaction before trying to close the connection.
Unless my code changes are wrong, it appears though that all the XA tests in
jdbc4 suite are non-global XA transactions. Is that right? The reason I ask is,
I had printlns in all the implementations of the new method
isInGlobalTransaction and they all always return false. I was expecting
following method in EmbedXAConnection.java to return true sometimes because we
are dealing with global XA transaction.
Index: java/engine/org/apache/derby/jdbc/EmbedXAConnection.java
===================================================================
--- java/engine/org/apache/derby/jdbc/EmbedXAConnection.java (revision 792143
)
+++ java/engine/org/apache/derby/jdbc/EmbedXAConnection.java (working copy)
@@ -22,6 +22,7 @@
package org.apache.derby.jdbc;
import org.apache.derby.impl.jdbc.Util;
+import org.apache.derby.iapi.jdbc.BrokeredConnectionControl;
import org.apache.derby.iapi.jdbc.EngineConnection;
import org.apache.derby.iapi.jdbc.ResourceAdapter;
@@ -53,6 +54,11 @@
xaRes = new EmbedXAResource (this, ra);
}
+ /** @see BrokeredConnectionControl#isInGlobalTransaction() */
+ public boolean isInGlobalTransaction() {
+ return isGlobal();
+ }
+
/**
* Check if this connection is part of a global XA transaction.
*
Can someone review this patch for me? There are not many comments yet. I will
put those soon.
I am right now also trying to work on a standalone repro case which will
reproduce our theory of local XA transaction not getting rolled back before
connection.close and hence the server shutdown does not happen correctly
causing next server start to hang.
> suites.All hang with message java.net.BindException: Address already in use:
> NET_Bind in derby.log
> ---------------------------------------------------------------------------------------------------
>
> Key: DERBY-4053
> URL: https://issues.apache.org/jira/browse/DERBY-4053
> Project: Derby
> Issue Type: Bug
> Components: Network Server, Test
> Affects Versions: 10.5.1.1
> Reporter: Kathey Marsden
> Attachments: derby-4053_repro_dont_commit_diff.txt, derby.log,
> DERBY4053_patch1_diff_July092009.txt, javacore-20090420-1735.txt,
> javacore.20090211.123031.4000.0001.txt, suites.All.out
>
>
> Running suites.All with IBM 1.5 on 10.5.0.0 alpha - (743198) I got a hang
> in the test run. The last test to run successfully was
> xtestNestedSavepoints, but I am not sure exactly what test caused the hang.
> I took a thread dump which I will attach, which showed network server up and
> running but no ClientThread and a ping attempt blocked.
> This hang is very similar to the hang that was seen after the fix attempts
> for DERBY-1465 but that change was backed out so it is not related to that
> change. It could be that the change for DERBY-1465 just made this highly
> intermittent problem more likely.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
