You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Julius Stroffek (JIRA)" <ji...@apache.org> on 2007/01/08 14:18:27 UTC
[jira] Created: (DERBY-2220) Transaction executed throught
XAResource will held locks forever (until commit is executed) and also
after the application terminates.
Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.
--------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-2220
URL: https://issues.apache.org/jira/browse/DERBY-2220
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.0.0
Environment: Solaris Nevada build 49, Sun's JDK1.6
Reporter: Julius Stroffek
Attachments: XATranTest.java, xxx.sql
Using this pieco of code derby will not release a table lock of 'dummy' table.
String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
XAResource xaResource = xaConnection.getXAResource();
conn = xaConnection.getConnection();
Xid xid = createXid(value);
xaResource.setTransactionTimeout(10);
xaResource.start(xid, XAResource.TMNOFLAGS);
Statement statement = conn.createStatement();
statement.execute(query);
// terminate the client application
// this will not release any locks
System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Prashant Bhagat (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478208 ]
Prashant Bhagat commented on DERBY-2220:
----------------------------------------
Hi Lance,
I'm working for the BPEL Service Engine team in the Alaska project.
Julius (from Java DB support team) has fixed a bug that I reported in
Derby and has created a patch. We would like to know
1. How and when do new releases of Derby get integrated in glassfish?
2. How do patches, such as this one, get integrated in glassfish?
Binod from the glassfish team gave me your reference and said that you
might know this. If not, do you know who the right person is who can
give this information.
Thanks
Prashant
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Derby Info: [Patch Available]
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Transaction executed throught
XAResource will held locks forever (until commit is executed) and also
after the application terminates.
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463032 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
The way how to reproduce the error:
Run the derby server on localhost (pass these options to java: -Dderby.locks.monitor=true -Dderby.locks.deadlockTrace=true). Execute a code in xxx.sql, run the XATransactionTest.java. Use ij tool to connect to a TestDB database on localhost. Execute the query 'select * from dummy;' After a couple of seconds you will get a message
ij> select * from dummy;
ERROR 40XL2: A lock could not be obtained within the time requested. The lockTable dump is:
2007-01-08 13:12:52.610 GMT
XID |TYPE |MODE|LOCKCOUNT|LOCKNAME |STATE|TABLETYPE / LOCKOBJ |INDEXNAME / CONTAINER_ID / (MODE for LATCH only) |TABLENAME / CONGLOM_ID |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
*** The following row is the victim ***
131 |ROW |S |0 |(1,7) |WAIT |T |NULL |DUMMY |
*** The above row is the victim ***
130 |ROW |X |1 |(1,7) |GRANT|T |NULL |DUMMY |
130 |TABLE |IX |1 |Tablelock |GRANT|T |NULL |DUMMY |
131 |TABLE |IS |1 |Tablelock |GRANT|T |NULL |DUMMY |
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this pieco of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475065 ]
Daniel John Debrunner commented on DERBY-2220:
----------------------------------------------
On the test changes in the patch:
J2EEDataSource already has methods to get XADataSources, so I don't think you need to add JDBCXADataSource.
This comment in the test concerns me:
+ // We need to do such a special setup for the test
+ // because if the locks are not released when the
+ // XAConnection object is closed the database
+ // can not be cleaned by CleanDatabaseSetup (throught defaultSuite)
+ // but DropDatabaseSetup (throught singelUseDatabaseDecorator)
+ // have to be used instead. This will ensures that the database
+ // will be cleaned after the test
Isn't this bug trying to address those issue? Having this style of cleanup will surely lead to bugs being hidden?
A safer approach would seem to be use the standard database and address/report issues as they appear.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-2220.
---------------------------------------
Resolution: Fixed
Fix Version/s: (was: 10.2.3.0)
10.2.2.1
Tests finished successfully on the 10.2 branch. Committed to 10.2 with revision 517320.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.3.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478263 ]
Mayuresh Nirhali commented on DERBY-2220:
-----------------------------------------
Prashant,
The patch has not made to the derby codebase yet. It will be reviewed
and committed by one of the committers. As for the release, the
community has not agreed on any release date for 10.3, but we are
working towards a release sometime this summer. Also, there is no update
release planned as of now on top of 10.2.2.
As per derby's integration in glassfish is concerned, I believe that is
completely handled by the glassfish team and driven by next
major/minor/update release of glassfish.
Although, there has not been a escalation associated with this
particular issue, this really is a internal customer escalation. We
would like to know about any time constraints you may have regarding
availability of this fix in glassfish ?? We can work towards that!
Thanks
Mayuresh
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek closed DERBY-2220.
----------------------------------
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.3.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-2220:
----------------------------------
Component/s: JDBC
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.2.2.0, 10.3.1.4
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assignee: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.1.4
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_fix.diff, d2220_fix.stat, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474689 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Dan, I agree with your comments and I will update the patch.
> I didn't look at the network code, but can local transactions use the new abortCurrentTransaction method DRDAXAProtocol?
> Using the term associated here with local connection is confusing, since associated is for XA global transactions..
I call the existing method DRDAXAProtocol.rollbackTransaction method in a new abortCurrentTransaction. Since the rollbackTransaction could be used for local transactions abortCurrentTransaction could be also used.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Affects Version/s: 10.2.3.0
Fix Version/s: 10.2.3.0
Thanks, Knut.
Yes, I would like to back-port the patch also. I applied the patch committed to trunk to 10.2 branch and it succeeded. I checked the sources and everything looks alright. Now, I am running the tests and once they will finish without failures, I will submit a patch against 10.2 branch.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.3.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by Daniel John Debrunner <dj...@apache.org>.
> Julius Stroffek commented on DERBY-2220:
> ----------------------------------------
>
> Dan: Thank you for explanation. It seems that I was reading a wrong book. ;-)
No, just not enough books. :-)
XA is a bit of a pain because once has to read the official distributed
transaction spec from X/Open (I think) and the JTA & JDBC specifications.
Then figure out how they interact ... :-)
Dan.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473075 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Dan: Thank you for explanation. It seems that I was reading a wrong book. ;-)
Knut: Yes, you are absolutely right - it will not work at all.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-2220.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.3.0.0
Derby Info: (was: [Patch Available])
Committed revision 517131. Should this fix be back-ported to the 10.2 branch?
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Summary: Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction). (was: Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.)
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483050 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Forgot to add that I ran derbyall and suites.All without failures except DERBY-2434.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_fix.diff, d2220_fix.stat, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478794 ]
Knut Anders Hatlen commented on DERBY-2220:
-------------------------------------------
Is point 2 (Forbid the call to XAConnection.close when there is a global transaction associated with the corresponding resource) a necessary part of this bug fix, or would it be better to discuss/fix it under a separate issue?
It seems to me the patch correctly implements what you have described. I'm a little confused after reading the discussion. Was there ever consensus that the described approach was correct? It does sound correct to me, but I haven't studied all the different standards mentioned.
Some small questions and comments to the try4 patch:
- could NetXAResource.currentXid have been private?
- abortCurrentTransaction() checks (e.errorCode != XAException.XA_RBOTHER && e.errorCode != XAException.XA_RBROLLBACK). Would it make sense to test (errorCode < XA_RBBASE || errorCode > XA_RBEND) instead?
- ClientPooledConnection (super class of ClientXAConnection) calls close() in its finalize method (existing code). With the new exception thrown by ClientXAConnection.close(), could that cause a problem when an active XAConnection is garbage collected?
- should XATransactionTest have been added to jdbcapi._Suite so that it runs under suites.All?
- I think the suite() method could be simplified to "return TestConfiguration.defaultSuite(...)"
- the Statement objects in testXAConnection() are not closed
- in previous discussions about JUnit tests it has been mentioned that referencing constants in org.apache.derby.shared.common.reference.SQLState in tests is not recommended. Instead one should hard code the SQL state (in this case "25000") in the test. Also, I would recommend using BaseJDBCTestCase.assertSQLState() instead of assertTrue(ex.getSQLState().equals...).
- there is a test for XAConnection.close() that is supposed to fail. What about adding a test case where it doesn't fail?
- I'm not a big fan of finally clauses in the tests, since exceptions in them might hide the original error. Putting the cleanup code outside the finally clause would only be a problem if the test fails, and I agree with Dan's previous comment about not optimizing tests for the time when they fail.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475081 ]
Daniel John Debrunner commented on DERBY-2220:
----------------------------------------------
The more worrying case is when locks are held on objects for which asserts do not exist on the test. Such a cleanup approach will hide those bugs.
I personally would not optimize tests for the time that they fail.
I also think that you've found an issue in the clean database decorator and as such it would be good to fix it centrally there, rather than in a single test. for example, if the clean database decorator failed to cleanup the database, it could report the failure and then blow away the database. This would not need to be part of this issue or addressed urgently, as your test would not rely on it as it will be passing, right :-)
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Mamta A. Satoor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472394 ]
Mamta A. Satoor commented on DERBY-2220:
----------------------------------------
Julius, I went through the patch and it looks good and well commented. I was curious though if the existing method rollbackTransaction(Xid xid) in DRDAXAProtocol can be used to do some/all of the work done by the new method abortCurrentTransaction()
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-2220:
--------------------------------------
Affects Version/s: (was: 10.2.3.0)
10.2.2.0
Changing affects version from 10.2.3.0 to 10.2.2.0 since there is no 10.2.3.0 yet.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480421 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
I am sorry, Knut, I misunderstood the comment about merging to 10.2, so I thought It was also committed. Thanks again! ;-)
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472571 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Mamta: The existing method will send also some DRDA stuff to the socket so the existing one can not be used. I can create a new method to do the common stuff for both methods but I decided that the code for it would be too simple.
Knut: Yes, I agree with you but currently I am not quite sure in which methods I can disassociate the transaction to be aborted. To clear the xid in endXA() is quite safe but I would like to consider also to clear it only during commit. The question is whether the global transaction might be committed on a different connection. I will try to dig this out.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Transaction executed throught
XAResource will held locks forever (until commit is executed) and also
after the application terminates.
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Description:
Using this piece of code derby will not release a table lock of 'dummy' table.
String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
XAResource xaResource = xaConnection.getXAResource();
conn = xaConnection.getConnection();
Xid xid = createXid(value);
xaResource.setTransactionTimeout(10);
xaResource.start(xid, XAResource.TMNOFLAGS);
Statement statement = conn.createStatement();
statement.execute(query);
// terminate the client application
// this will not release any locks
System.exit(0);
was:
Using this pieco of code derby will not release a table lock of 'dummy' table.
String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
XAResource xaResource = xaConnection.getXAResource();
conn = xaConnection.getConnection();
Xid xid = createXid(value);
xaResource.setTransactionTimeout(10);
xaResource.start(xid, XAResource.TMNOFLAGS);
Statement statement = conn.createStatement();
statement.execute(query);
// terminate the client application
// this will not release any locks
System.exit(0);
> Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_try2.stat
d2220_try2.diff
The test suites finished successfully except the junit JDBCHarnessJavaTest which fails me also on trunk.
Just for explanation of changes to embedded driver:
When I wrote a test I tried it to run also using the embedded driver and it fails with the XAER_PROTO exception. However, I do not see any reason why this test should not succeed since closing the socket on network connection and closing an embedded connection should behave the same from this point of view.
Any comments?
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_try1.stat
d2220_try1.diff
I implemented a change as it was in first proposal. I added the same behaviour also to embedded connection and implemented a test. I added a JDBCXADataSource similar to JDBCDataSource to be able to obtain a XAConnection and XAResource instances.
btw: Does anybody knows the use case for XADataSourceConnector? I think it is useless for XA transaction since it does not provide a way how to obtain a corresponding XAResource object.
Comments are welcomed.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Transaction executed throught
XAResource will held locks forever (until commit is executed) and also
after the application terminates.
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: xxx.sql
XATranTest.java
> Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this pieco of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466753 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
A discussion about the issue at derby-dev could be found at:
http://www.nabble.com/Rollback-is-not-executed-only-for-XA-sessions-after-the-socket-is-closed.-tf2940001.html#a8220033
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474222 ]
Daniel John Debrunner commented on DERBY-2220:
----------------------------------------------
Could you confirm what the patch does. Your first proposal seems to say that if the socket is closed the connection is rolled back,
but then you add the same behaviour for embedded, but embedded doesn't use sockets, so I'm not clear what you intend the
embedded behaviour to be. Thanks.
Re XADataSourceConnector;
.
As its javadoc says "Returns a connection in local mode obtained from getXAConnection().getConnection()"
It probably could be named better, unless it could be expanded to also provide global transaction support)
I think it's there to allow tests to run using a connection object from an XADataSource that remains in local mode.
Thus allowing increased coverage.
E.g. one could imagine running all the jdbcapi & jdbc4 tests in multiple connection modes to ensure complete testing:
DriverManager.getConnection
DataSource
XADataSource (local & global)
ConnectionPoolDataSource
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472407 ]
Knut Anders Hatlen commented on DERBY-2220:
-------------------------------------------
I agree with Mamta that the patch looks good. I have one questions, though:
The xid field in DRDAXAProtocol is only reset to null in abortCurrentTransaction(). Should it also be reset in other methods, for instance in endXA()? It seems to me that abortCurrentTransaction() will always be called when the client disconnects, even when it has done the required cleanup first.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475048 ]
Daniel John Debrunner commented on DERBY-2220:
----------------------------------------------
Julius wrote: "When I wrote a test I tried it to run also using the embedded driver and it fails with the XAER_PROTO exception. However, I do not see any reason why this test should not succeed since closing the socket on network connection and closing an embedded connection should behave the same from this point of view. "
I'm a little lost here as I'm still unclear of what you intend the patch to do (see my first comment on 19th feb).
For the network server I thought this was addressing the case when the socket became closed due to unexpected behaviour, like the client application quitting, or the network link going down.
For embedded however, the physical connection cannot break that way (?), so the code seems to be addressing the case where an explicit close is performed by the application or the transaction manager. Is this the intention? Does the network client work the same way? Should this infact be a protocol error as it is a violation of the api by the transaction manager?
A quick summary of what you intend the patch to do would be great.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: (was: XATranTest_V2.java)
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472822 ]
Daniel John Debrunner commented on DERBY-2220:
----------------------------------------------
JDBC spec is very clear on this (JDBC 3.0 section 12.4.1)
"The transaction manager is not required to use the same XAResource object to
commit/rollback a transaction branch as was used to execute the branch. If different
XAResource objects are used, however, they must be associated with
XAConnection objects that connect to the same resource manager."
Thus you cannot force the application to commit using the same XAResource.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_beta2.diff
What about the second patch?
I changed the code to maintain the list of all uncommitted transactions and rollback all of them. This should cover the whole problem not only the previous simple case.
The patch will forbid using the code like this one
XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1526/TestDB", "", "");
XAResource xaResource = xaConnection.getXAResource();
conn = xaConnection.getConnection();
XAConnection xaConnection2 = createXAConnection("jdbc:derby://localhost:1526/TestDB", "", "");
XAResource xaResource2 = xaConnection2.getXAResource();
Xid xid = createXid(value);
xaResource.start(xid, XAResource.TMNOFLAGS);
Statement statement = conn.createStatement();
statement.execute(query);
xaResource.end(xid, XAResource.TMSUCCESS);
// commiting a transaction on different resource
xaResource2.prepare(xid);
xaResource2.commit(xid, false);
It will force the user to commit or rollback the transaction on a same connection as it was executed. I went through JTA API and have not found anything that will state that the JTA implementation have to allow commit/rollback of a transaction on different connection than the unit of work was executed on. At least the specification forbids resuming a suspended transaction on different connection than it was started on. Then I think made also no sense to require to commit or rollback the transaction on the different connection than the unit of work was executed on.
There exists 1:1 mapping between XAConnection instance and XAResource instance. The XAResource methods use the corresponding logical connection to pass commands to a database.
Please provide any further comments on this.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Derby Info: [Patch Available]
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_fix.diff, d2220_fix.stat, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480115 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Oohhh, great. Thanks, Knut.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.3.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466760 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
I spent more time trying to dig out something... There is a good description about the derby implementation in the source of org.apache.derby.iapi.jdbc.ResourceAdapter interface.
There exist a 1:1 mapping between XAConnection instance and XAResource instance.
The behaviour how the driver should behave if the connection willl be closed is not covered by the JTA specification at all. The XAResource could be in the following states:
* Not Associated with global transaction
* Associated with global transaction
* Association Suspended
According the JTA Specification if the transaction is suspended, it have to be only resumed, finished with success or error on the same XAResource instance. At least transaction association table shows that the XAResource instance could not be used for something else than calling end(TMRESUME), end(TMFAIL) and end(TMSUCCESS). I found somewhere in code that the derby implements this in the same way (can not find the comment again, still trying ;-).
It seems that it should be fairly easy and safe to roll back an XA transaction when the logicall connection will be closed by the client and the transaction was in Associated state on that connection.
However, there is still the case when all the transaction branches are dissassociated from the connections but the application had not done commit or roll back yet and will never do that in the future (wrong code, or application crash). It seems to me that the only one solution to this is to implement some sort of configurable time out for inactivity for global transaction on XAResource instances. Any other suggestions?
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_try5.stat
d2220_try5.diff
This patch covers only the case when the socket from the client's connection is closed and the global transaction was associated with the connection. In this case, the global transaction will be rolled back. The test for this behavior is not written yet and I plan to cover this in DERBY-2421 with a test for the proper garbage collection.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek reopened DERBY-2220:
------------------------------------
I found an error in the patch. The fix will follow immediately.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472838 ]
Knut Anders Hatlen commented on DERBY-2220:
-------------------------------------------
Hi Julo,
I don't know enough about XA to answer your questions, but I have some general comments to the patch:
I might be missing something, but doesn't this part of abortTransactions() cause a NullPointerException?
+ Xid[] xids = null;
+ Collection coll = this.xids.values();
+ if (coll != null && coll.size() > 0) {
+ xids = (Xid []) coll.toArray(xids);
When calling coll.toArray(xids), xids is always null, isn't it? Also, I think abortTransactions() would be simpler if it used xids.values().iterator() directly instead of converting the collection to an array.
I'm not sure I see the value of the removeXid parameter to rollbackTransaction(). It might micro-optimize abortTransactions(), but given that abortTransaction() is only invoked in exceptional situations, I don't think it justifies the extra complexity.
The patch makes some of the lines in DRDAXAProtocol exceed 80 characters, which should be avoided.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_beta.diff
I have created a proposal for the patch.
It covers only the simple case (for the network driver) when the global transaction is associated with the connection and the application closes the socket. The last transaction associated with the connection will be aborted. I ran the derbyall and suites.All without any failures.
I would add one more line to DRDAXAProtocol.endXA
"this.xid = null;"
to do rollback only for transactions in unit of work.
Please, provide any comments.
Finally, I will write also a test.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_try4.stat
d2220_try4.diff
This patch implements the following:
1.) Rollback the global transaction on a derby server when the network socket is closed.
2.) Forbid the call to XAConnection.close when there is a global transaction associated with the corresponding resource. Similar code is added to the embedded driver and client driver as well. The state of the connection is not changed at all.
3.) Test for 2.) is added. I did not write a test for 1.) because I find it a bit more difficult since a test does not have an access to the underlying code to close the socket.
Because the XAConnection is a subclass of PooledConnection object the close method throws only SQLException and not XAException. According DTP XA Spec the xa_close should return XAER_PROTO which should map to XAException. This is not possible and the same SQLException is thrown now as the embedded driver did before. I added the code for embedded driver to handle XA case separately because the connection was left in a state when it could not be used anymore.
Any comments?
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474210 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Forgot to add that I ran derbyall and Suites.All with two failures in Suites.All. Both of these failures appear to me also on trunk without any modifications.
The failing tests are:
org.apache.derbyTesting.functionTests.tests.jdbcapi.JDBCHarnessJavaTest
org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner updated DERBY-2220:
-----------------------------------------
Derby Info: (was: [Patch Available])
Patch (as comments show) does not implement the spec for close() correctly so unsetting the patch available flag.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-2220) Transaction executed throught
XAResource will held locks forever (until commit is executed) and also
after the application terminates.
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek reassigned DERBY-2220:
--------------------------------------
Assignee: Julius Stroffek
> Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-2220) Transaction executed throught
XAResource will held locks forever (until commit is executed) and also
after the application terminates.
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12463055 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
The problem is in the org.apache.derby.impl.drda.Database class.
The function close() contains the following code:
if ((conn != null) && !conn.isClosed())
{
if (! forXA)
{
conn.rollback();
}
conn.close();
}
Thus, the rollback() is not executed for XA connection. Anybody knows the reason why?
> Transaction executed throught XAResource will held locks forever (until commit is executed) and also after the application terminates.
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: d2220_fix.stat
d2220_fix.diff
In DRDAXAProtocol the null value was assigned to a local variable instead of the global one. This causes the last transaction to be rolled back after the connection will be closed even if the XAResource.end was called before.
Lesson learned: Better, do not use the same names for arguments and class members.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_fix.diff, d2220_fix.stat, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek closed DERBY-2220.
----------------------------------
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assignee: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_fix.diff, d2220_fix.stat, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Attachment: XATranTest_V2.java
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: XATranTest.java, XATranTest_V2.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen reopened DERBY-2220:
---------------------------------------
Reopening to port to 10.2.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.3.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479343 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
> Is point 2 (Forbid the call to XAConnection.close when there is a global transaction
> associated with the corresponding resource) a necessary part of this bug fix,
> or would it be better to discuss/fix it under a separate issue?
Ok Knut, to make thinks simpler for discussion I have created a separate issue for this - DERBY-2420. I will move the discussion there...
> abortCurrentTransaction() checks (e.errorCode != XAException.XA_RBOTHER && e.errorCode != XAException.XA_RBROLLBACK).
> Would it make sense to test (errorCode < XA_RBBASE || errorCode > XA_RBEND) instead?
Yes, it would. Thanks, I have not noticed that fields in XAException.
> - there is a test for XAConnection.close() that is supposed to fail. What about adding a test case where it doesn't fail?
I think, this case is already covered by xaSimplePositive.sql and xaSimpleNegative.sql and other XA tests.
And I completely agree with all your other comments. I'll prepare a patch for those under the new issue.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475103 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
>From the XA Transaction Specification from the OpenGroup:
---
It is an error, [XAER_PROTO], for a transaction manager to call xa_close () within a
thread of control that is associated with a transaction branch (that is, the transaction
manager must call xa_end() before calling xa_close ()).
---
So a change proposed in a patch is against this spec. It should be possible to close a xa network connection on the trunk but not the ebedded one. To implement this according a spec should be:
1.) undo any changes made to embedded connection
2.) check in the network client code (ClientXAConnection) when closing a connection to a database whether it is already associated with the global transaction. If so, do not allow a connection to be closed.
However, from my point of view it would be clearer to allow a connection to be closed and rollback the associated transactions. I do not know whether it would be possible to even make the behavior against the spec in some cases but I would like to discuss the difference.
I would expect that a transaction manager or an application would call the XAConnection.close when it is associated with a transaction only in a exceptional case when it 'does not know what else to do'. This could happen after throwing an unpredictable exceptions which do not have to be handled - like NullPointerException. The handling of such an exception usually propagates through couple of functions in the call stack. Usually, in this case the application do not have to know the valid xid of the transaction or it do not have to know even whether the xa connection is associated with the transaction or not. What the application should do?
1.) If it uses a transaction manager, the xid is stored in a transaction manager and if it has a reference to transaction manager it can do some work with the transaction - probably roll back
2.) If it uses XAResource and XAConnection directly, it may happen that the application will loose xid and not the XAResource or XAConnection references (these might be shared across the application). What to do in this case?
I am trying to think of an application with not the optimal design. This leads me what happens if all the objects would be garbage collected? ;-)
---
Now I think that the best approach is to implement XAConnection.close according the specs and to provide the cleanup with rollback of transactions in XAConnectionImpls.finalize methods (as it is implemented now in close methods of the patch). I checked the code for this fastly and it looks like it is not handled this way. I'll check this in more detail and I'll create a new jira issue to address this separately.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12480106 ]
Knut Anders Hatlen commented on DERBY-2220:
-------------------------------------------
I don't think a new patch is required. The fix merged cleanly to 10.2 with this command:
svn merge -c 517131 ../trunk
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.3.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.3.0, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474230 ]
Daniel John Debrunner commented on DERBY-2220:
----------------------------------------------
Looking at the patch I think you describe the same situation in three different ways:
1) global transaction in unit of work [ not sure if unit of work is the correct description here]
2) XA transaction if it was not disassociated from the connection [ double negative ]
3) global/local transaction associated with the connetion [ local transactions are not associated]
I think this makes the code confusing for later readers who will not have the benefit of seeing all three together.
I think the correct terminology would be (I assume this is what the patch intends):
- If the global transaction is associated with the XAResource and the physical connection is closed then rollback the
global transaction.
For the changes to EmbedXAConnection I think two changes are needed:
- end the transaction with TMFAIL (resource manager will mark it as rollback-only)
- do not print the XAException to System.err. The embedded driver must throw its exceptions to
the calling program, in this case you need to wrap it in a SQLException
I didn't look at the network code, but can local transactions use the new abortCurrentTransaction method DRDAXAProtocol?
Using the term associated here with local connection is confusing, since associated is for XA global transactions..
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julius Stroffek updated DERBY-2220:
-----------------------------------
Derby Info: [Patch Available]
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479422 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
Knut, sorry I forgot to explain your important comment:
> It seems to me the patch correctly implements what you have described. I'm a little confused after reading the discussion.
> Was there ever consensus that the described approach was correct? It does sound correct to me, but I haven't studied
> all the different standards mentioned.
In Derbby XAConnection and XAResource instances are mapped 1:1. The methods of XAResource instance in network driver use the XAConnection instance to send all the DRDA commands throught the socket. Thus if the socket will be closed when the transaction is associated with the connection, there is no way how to continue the work on that transaction. You can not join that transaction, you can not end the association of that transaction, you can not rollback nor commit the transaction. The locks held by the transaction will not be released. This is not covered by the any of these specs and the proposed behavior can be only done because of the way how derby implements the spec - it uses the same socket for both - XAConnection and XAResource.
If derby would use a different socket for the XAResource object than the XAConnection, this would not be possible because if the connection would be closed you could still end the association of the transaction with the resource, but this is not possible in derby.
I think all these facts are mentioned in the discussion but there is no summary explaining it.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-2220.
---------------------------------------
Resolution: Fixed
Derby Info: (was: [Patch Available])
Thanks for the fix, Julo!
Committed to trunk with revision 521609.
Committed to 10.2 with revision 521610.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.2.2.0, 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Fix For: 10.2.2.1, 10.3.0.0
>
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_fix.diff, d2220_fix.stat, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479537 ]
Knut Anders Hatlen commented on DERBY-2220:
-------------------------------------------
Thanks for the explanation and for splitting the patch. It's much clearer to me now. I have started the regression tests. If they pass and no one objects to this approach within a couple of days, I will commit the try5 patch.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, d2220_try5.diff, d2220_try5.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Mayuresh Nirhali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mayuresh Nirhali updated DERBY-2220:
------------------------------------
Comment: was deleted
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, d2220_try4.diff, d2220_try4.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12475075 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
> Isn't this bug trying to address those issue? Having this style of cleanup will surely lead to bugs being hidden?
> A safer approach would seem to be use the standard database and address/report issues as they appear.
Yes, the bug addresses exactly this issue.
However, If I will use CleanDatabaseTesetSetup instead of the DropDatabaseTestSetup and the bug will appear again the test will lock for a while in CleanDatabaseTestSetup (need to timeout 5 times in CleanDatabaseTestSetup.removeObjects trying to obtain lock). I tried to run a test also on a code not fixied yet.
If the lock is not released the following select statement raise an exception. The engine is shutted down afterwards and the database is dropped which is much faster and also detects the bug.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, d2220_try2.diff, d2220_try2.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2220) Uncommitted transactions executed
throught XAResource will held locks after the application terminates (or
crashes during the transaction).
Posted by "Julius Stroffek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12474776 ]
Julius Stroffek commented on DERBY-2220:
----------------------------------------
I tried this simple test program to run against trunk to find out whether it is possible to join a global transaction after a connection is closed from a different connection and recover in this way. The following code stopped in endless wait on xaResource2.start(xid, XAResource.TMJOIN) waiting for a transaction to be disassociated from the connection already closed.
xaResource.start(xid, XAResource.TMNOFLAGS);
Statement statement = conn.createStatement();
statement.execute(query);
xaConnection.close();
xaResource2.start(xid, XAResource.TMJOIN);
xaResource2.end(xid, XAResource.TMSUCCESS);
xaResource2.commit(xid, true);
System.exit(0);
-------
Dan: I applied your comments except that in Embedded driver I do not used the TMFAIL flag because handling a one more exception separately would make the code a bit worse readable. I think there is no difference in this since the transaction is rollbacked on the following line. It will be explained in a comment. The only difference is a case when the rollback fails, but I am not sure what else we can do with a transaction which cannot be committed and fails to rollback.
I am running test suites now and I will post a new patch tomorrow.
> Uncommitted transactions executed throught XAResource will held locks after the application terminates (or crashes during the transaction).
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2220
> URL: https://issues.apache.org/jira/browse/DERBY-2220
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.3.0.0
> Environment: Solaris Nevada build 49, Sun's JDK1.6
> Reporter: Julius Stroffek
> Assigned To: Julius Stroffek
> Attachments: d2220_beta.diff, d2220_beta2.diff, d2220_try1.diff, d2220_try1.stat, XATranTest.java, xxx.sql
>
>
> Using this piece of code derby will not release a table lock of 'dummy' table.
> String query = "insert into dummy (field1) values ('" + Integer.toString(value) + "')";
> XAConnection xaConnection = createXAConnection("jdbc:derby://localhost:1527/TestDB", "", "");
> XAResource xaResource = xaConnection.getXAResource();
> conn = xaConnection.getConnection();
>
> Xid xid = createXid(value);
> xaResource.setTransactionTimeout(10);
> xaResource.start(xid, XAResource.TMNOFLAGS);
>
> Statement statement = conn.createStatement();
> statement.execute(query);
>
> // terminate the client application
> // this will not release any locks
> System.exit(0);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.