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 "Brett Bergquist (Created) (JIRA)" <ji...@apache.org> on 2011/12/30 15:37:30 UTC
[jira] [Created] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
------------------------------------------------------------------------------------------------------------
Key: DERBY-5562
URL: https://issues.apache.org/jira/browse/DERBY-5562
Project: Derby
Issue Type: Bug
Components: Network Server
Affects Versions: 10.8.2.2
Environment: Solaris 10
Glassfish V2.1.1
Reporter: Brett Bergquist
>From the EmbedConnection.java comment for "xa_prepare".
// On a prepare call, xa allows an optimization that if the
// transaction is read only, the RM can just go ahead and
// commit it. So if store returns this read only status -
// meaning store has taken the liberty to commit already - we
// needs to turn around and call internalCommit (without
// committing the store again) to make sure the state is
// consistent. Since the transaction is read only, there is
// probably not much that needs to be done.
When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5562) An read-only XA transaction that
has a timeout never has the timer canceled when the transaction is complete
Posted by "Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184563#comment-13184563 ]
Brett Bergquist commented on DERBY-5562:
----------------------------------------
It appears the timer was implemented in https://issues.apache.org/jira/browse/DERBY-2508 which has a fix at 10.3.1.4
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5562) An read-only XA transaction that
has a timeout never has the timer canceled when the transaction is complete
Posted by "Brett Bergquist (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13183253#comment-13183253 ]
Brett Bergquist commented on DERBY-5562:
----------------------------------------
The failure is that the transaction timeout is not canceled when it should be and will produce a message in the log when this is the case.
The test needs to create a XA transaction with timeout (I used the derby.jdbc.xaTransactionTimeout to set the timeout), start the XA transaction, use read-only SQL to the database and then prepare the XA transaction. The prepare code detects that only read-only work was done and implicitly commits the transaction. The prepare returns XA_RDONLY and you do not commit the transaction in the test code. The timer started by the "start" method will not be canceled and the timer will continue and when fired will try to rollback the transaction that has already be implicitly committed and ended.
See issue
https://issues.apache.org/jira/browse/DERBY-960
which fixed the prepare to return XA_DDONLY.
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Attachments: D5562.java, DERBY-5562.patch
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Brett Bergquist (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brett Bergquist updated DERBY-5562:
-----------------------------------
Attachment: DERBY-5562.patch
A patch to fix this problem. This calls XATransactionState.xa_finalize() to release the timer because no call to rollback or commit is going to come for a read-only transaction.
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Attachments: DERBY-5562.patch
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Knut Anders Hatlen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5562:
--------------------------------------
Attachment: d5562-1a-with-test.diff
Thanks. The attached patch adds a test case that exposes the bug. It prepares a read-only transaction that has a timeout, and then starts a new transaction with the same Xid and no timeout. The second transaction sleeps for while to make sure it exceeds the timeout of the first transaction. The second transaction is aborted because of the bug, and the test case fails. With the fix, the transaction is not aborted, and the test case passes.
The patch also moves the fix from EmbedXAResource to XATransactionState, so that all handling of the timer is private to that class. I also made XATransactionState.xa_finalize() private to emphasize this (and removed the synchronized modifier since all callers already synchronize before calling the method).
All the regression tests ran cleanly with this patch.
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Knut Anders Hatlen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5562:
--------------------------------------
Attachment: D5562.java
I'm attempting to write a test for this bug. What symptom should I be looking for? The bug description mentions that the cancellation timer will fail as the transaction no longer exists after preparing a read-only transaction.
I tried to reproduce this by running the attached program, which prepares a read-only transaction with a 20 second timeout. After 20 seconds, I see the following printed to derby.log:
The XA transaction timed out and is going to be rolled back. The transaction Xid is (1,0102,0304).
However, I don't see any failures. What's missing in order to reproduce the failures?
(I guess an alternative way to reproduce the bug would be to start a new transaction using the same xid after preparing the first one, and checking if the second transaction gets cancelled by the timer from the first transaction.)
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Attachments: D5562.java, DERBY-5562.patch
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Knut Anders Hatlen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5562:
--------------------------------------
Issue & fix info: (was: Patch Available)
Committed to trunk with revision 1230480. I also plan to backport the fix to 10.8.
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Knut Anders Hatlen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5562:
--------------------------------------
Issue & fix info: Patch Available
Assignee: Knut Anders Hatlen
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5562) An read-only XA transaction that
has a timeout never has the timer canceled when the transaction is complete
Posted by "Dag H. Wanvik (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184112#comment-13184112 ]
Dag H. Wanvik commented on DERBY-5562:
--------------------------------------
Looks good to me. I tried the test without the patch and it failed as expected. +1
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5562) An read-only XA transaction that
has a timeout never has the timer canceled when the transaction is complete
Posted by "Mike Matrigali (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184446#comment-13184446 ]
Mike Matrigali commented on DERBY-5562:
---------------------------------------
change and test look good to me. Any idea how many versions back this problem affects?
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Knut Anders Hatlen (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen updated DERBY-5562:
--------------------------------------
Component/s: (was: Network Server)
JDBC
Fix Version/s: 10.9.0.0
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Fix For: 10.9.0.0
>
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-5562) An read-only XA transaction that has
a timeout never has the timer canceled when the transaction is complete
Posted by "Knut Anders Hatlen (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-5562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Knut Anders Hatlen resolved DERBY-5562.
---------------------------------------
Resolution: Fixed
Fix Version/s: 10.8.2.3
The nightly tests passed on all platforms with the fix, and so did a manual run of the tests with the fix on the 10.8 branch (except one occurrence of DERBY-5498). Backported to 10.8 and committed revision 1230914.
> An read-only XA transaction that has a timeout never has the timer canceled when the transaction is complete
> ------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5562
> URL: https://issues.apache.org/jira/browse/DERBY-5562
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.8.2.2
> Environment: Solaris 10
> Glassfish V2.1.1
> Reporter: Brett Bergquist
> Assignee: Knut Anders Hatlen
> Fix For: 10.8.2.3, 10.9.0.0
>
> Attachments: D5562.java, DERBY-5562.patch, d5562-1a-with-test.diff
>
>
> From the EmbedConnection.java comment for "xa_prepare".
> // On a prepare call, xa allows an optimization that if the
> // transaction is read only, the RM can just go ahead and
> // commit it. So if store returns this read only status -
> // meaning store has taken the liberty to commit already - we
> // needs to turn around and call internalCommit (without
> // committing the store again) to make sure the state is
> // consistent. Since the transaction is read only, there is
> // probably not much that needs to be done.
> When XATransactionController.XA_RDONLY is returned, no "commit" or "rollback" will be received. If a XA transaction timer was started (could be through the derby.jdbc.xaTransactionTimeout=xxx for example), then these transactions will not have their timer canceled and will later attempt to cancel the transaction and fail as the transaction no longer exists.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira