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 "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2006/02/21 19:09:22 UTC
[jira] Created: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
----------------------------------------------------------------------------------------------------------
Key: DERBY-1016
URL: http://issues.apache.org/jira/browse/DERBY-1016
Project: Derby
Type: Bug
Components: JDBC
Versions: 10.2.0.0, 10.1.2.3, 10.1.3.0
Reporter: Kathey Marsden
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
in the XA+
specification, it seems like xa_forget should only be valid for a
heuristically completed transaction, so should be XAER_PROTO
and not XAER_NOTA.
In xaStateTran.sql we have this case:
-- get back into prepared state
xa_start xa_noflags 50;
insert into xastate values(2);
xa_end xa_success 50;
xa_prepare 50;
select * from global_xactTable where gxid is not null order by gxid;
-- the following should error XAER_NOTA
xa_forget 50;
The user code I am looking at handles forget like this. They expect
XAER_PROTO in this case.
try {
xaRes.forget(xidList[i]);
System.out.print("XA-Transaction [" + (i+1) + "]
Forgotten. \n" );
} catch (XAException XAeForget) {
if ( XAeForget.errorCode ==
XAException.XAER_PROTO ) {
System.out.print("XA-Transaction [" + (i+1)
+ "] not heuristically completed yet - Rolling Back instead. \n" );
xaRes.rollback(xidList[i]);
System.out.print("XA-Transaction [" + (i+1)
+ "] Rolled Back. \n" );
}
if ( XAeForget.getMessage() != null ) {
System.out.println("XAException " +
XAeForget.getMessage() );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710693#action_12710693 ]
Ravinder Reddy commented on DERBY-1016:
---------------------------------------
I am getting the following error when I try to reproduce the error for DERBY-1016
ReproDerby1016.java:26: cannot find symbol
symbol : class utilXid
location: class ReproDerby1016
Xid xid = new utilXid(1,93,18);
^
1 error
More Info about the Derby Setup:
I have checked-out truck source in windows machine and built it using Ant.
I have created a lib folder in home directory and copied all jars (jars/sane/*.jar) to lib and set the DERBY_HOME , path , classpath accordingly.
I have put classes folder also in classpath.
what might be the Error.?
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: ReproDerby1016.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ravinder Reddy updated DERBY-1016:
----------------------------------
Attachment: DERBY-1016_Patch_1.diff
As pointed out by Kathey , It seems that the error lies in the conditional evaluation of tranState.isPrepared in EmbedXAResource.forget().
Attached is the first/quick/small patch to it , please review and give your comments.
Thank you
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-1016:
----------------------------------
Attachment: ReproDerby1016.java
This appears to be a problem for both embedded and network server. Attached is a reproduction. As is it runs with embedded but you can comment/'uncomment a few lines to run with Client.
There is this highly suspect code in EmbedXAResource.forget() which may be relevant:
throw new XAException(tranState.isPrepared
? XAException.XAER_NOTA
: XAException.XAER_PROTO);
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Attachments: ReproDerby1016.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Dag H. Wanvik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dag H. Wanvik updated DERBY-1016:
---------------------------------
Issue & fix info: [High Value Fix, Newcomer] (was: [Newcomer])
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741581#action_12741581 ]
Tiago R. Espinha commented on DERBY-1016:
-----------------------------------------
I checked the specification that Kathey posted and here's what it has to say about forgetting transactions:
[XAER_NOTA]
The specifiedXIDis not knownbythe resource manager as a heuristically
completedXID.
and
[XAER_PROTO]
The routine was invoked in an improper context. See Chapter 6 for details.
On further reading, it says the following:
If a resource manager does not recognise ∗xid, the function fails, returning
[XAER_NOTA].
So, I think this is pretty clear that XAER_NOTA is specifically for when we attempt to do an operation on a transaction that is not recognized by the resource manager. Therefore, I think that as long as the transaction exists, the xa_forget call should always return XAER_PROTO in the event of an exception.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742985#action_12742985 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
That behavior sounds reasonable to me and provides the most intuitive user feedback I think. We should have a release note describing the cases that change.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741421#action_12741421 ]
Tiago R. Espinha commented on DERBY-1016:
-----------------------------------------
If I understood this properly, XA.forget does return different exceptions depending on the status of the transaction. With this in mind, we probably need to change one occurrence of the XA.forget in the harness test to accommodate for the fact that the exception being thrown for this specific case is now different.
Is this correct?
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-1016:
----------------------------------
Derby Categories: [High Value Fix, Newcomer]
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Attachments: ReproDerby1016.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717281#action_12717281 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
Hi Ravinder,
I just wanted to check in on this issue. It would be great to get it committed by July 14,our target release candidate date. Do you think you will have time to work on it between now and then?
Thanks
Kathey
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741104#action_12741104 ]
Myrna van Lunteren commented on DERBY-1016:
-------------------------------------------
Thanks Tiago for your email to the list indicating you ran suites.All successfully.
However, I thought it prudent to run derbyall (with ibm16 and sane classes), and it popped one new test failure (apart from a failure in unit/T_RawStoreFactory.unit, similar to the closed DERBY-654, which we can ignore here because I often get it on my machine with this configuration):
jdbcapi/xaSimpleNegative.sql. This test apparently already had a test for the XaResource.forget...
And as expected, it now shows XAER_PROTO instead of XAER_NOTA.
However, it has another test case of XAResource.forget, and that now returns XAER_NOTA instead of XAER_PROTO
Looking at the code change, this is logical, but I'm just not sure that we're doing the right thing.
Should both cases return XAER_PROTO?
I looked at the diff for a while, but would like to get the opinion of someone who understands/knows the XA specs better....
This is the flip/flop section:
-------------------------------------------------
ij(XA)> -- start one
xa_start xa_noflags 1;
ij(XA)> -- ERROR: can only forget heuristically completed transaction
xa_forget 1;
IJ ERROR: XAER_NOTA <---returns XAER_PROTO after patch
ij(XA)> delete from APP.negative;
1 row inserted/updated/deleted
ij(XA)> xa_end xa_success 1;
ij(XA)> -- ERROR: now try some bad flag
xa_start xa_suspend 1;
IJ ERROR: XAER_INVAL
ij(XA)> -- ERROR: now try some bad flag
xa_start xa_fail 1;
IJ ERROR: XAER_INVAL
ij(XA)> xa_prepare 1;
ij(XA)> -- can only forget heuristically completed transaction
xa_forget 1;
IJ ERROR: XAER_PROTO <--returns XAER_NOTA after patch
--------------------------------------------------------------
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742050#action_12742050 ]
Tiago R. Espinha commented on DERBY-1016:
-----------------------------------------
Me and Kathey have been testing the repro in this issue under both PostgreSQL and DB2. As it turns out, PostgreSQL fails and DB2 passes. The failure I get on PostgreSQL reads as follows:
FAIL: got unexpected exception Heuristic commit/rollback not supported errorCode: -4 calling forget on a prepared transaction
It is throwing an error code -4. If we check the XAException class we can see that the error being thrown is actually an XAER_NOTA as opposed to the expected XAER_PROTO.
However, per Kathey's testing, we do get XAER_PROTO on DB2.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-1016:
----------------------------------
Issue & fix info: [High Value Fix, Known fix, Newcomer, Repro attached] (was: [Repro attached, Newcomer, High Value Fix])
Assignee: (was: Ravinder Reddy)
Ravinder told me offline that he would not be able to work on this for a while. Unassigning so someone else can finish it off. I think the code change is ok. We just need a new test.
Ravinder, I hope you will be able to come back in the near future and pick up another issue.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717623#action_12717623 ]
Ravinder Reddy commented on DERBY-1016:
---------------------------------------
Hi Kathey,
I think I can complete by then.
thank you
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha updated DERBY-1016:
------------------------------------
Attachment: DERBY-1016.patch
I'm attaching a second patch that adds a new fixture to XATransaction to test for the existence of this bug. With Ravinder's patch, the fixture passes correctly. I'll be running suites.All with both patches on.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714084#action_12714084 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
Hi Ravinder,
I think the code change looks ok. Please add a test to XATransactionTest. You should also run XATest (currently not in a suite DERBY-4155) to make sure there are no issues associated with the change and let us know the results of your Suites.All and derbyall runs.
Thanks
Kathey
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha reassigned DERBY-1016:
---------------------------------------
Assignee: (was: Tiago R. Espinha)
Unassigning as I'm working on DERBY-728 and other people might pick this up in the meanwhile.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741948#action_12741948 ]
Myrna van Lunteren commented on DERBY-1016:
-------------------------------------------
I messed up my comment. I had modified the .out to check that it would make the test pass, and instead of from the original .out, I pasted my comment using the modified one.
So....
xaSimpleNegative has 2 cases of using of xa_forget:
1:
ij(XA)> -- start one
xa_start xa_noflags 1;
ij(XA)> -- ERROR: can only forget heuristically completed transaction
xa_forget 1;
IJ ERROR: XAER_PROTO <-- returns XAER_NOTA after the patch
2.:
ij(XA)> xa_prepare 1;
ij(XA)> -- can only forget heuristically completed transaction
xa_forget 1;
IJ ERROR: XAER_NOTA <-- returns XAER_PROTO after the patch
I'm sorry for the confusion.
So, based on this, I think the result after the patch makes perfect sense based on the change the patch does...But are both correct?
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kathey Marsden updated DERBY-1016:
----------------------------------
Attachment: utilXid.java
My bad, I neglected to attach this file.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742086#action_12742086 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
DB2 also returns XAER_PROTO for the case where forget() is called after start() (This case now returns XAER_NOTA with the patch)
My understanding is that Informix also returns XAER_PROTO for both cases but I have not confirmed that myself.
Tiago found Postgress returned XAER_NOTA in both cases.
A couple things to note when trying to sort out the spec and our behavior.
1) There are no positive cases for forget() with Derby I think. We do not have a method for heuristic completion, so it is just a matter of which error to throw. In the xa spec under xa_fprget() it says:
XAER_NOTA - The specified XID is not known by the resource manager as a heuristically completed XID.
XAER_PROTO - The routine was invoked in an improper context.
2) For the original case on which this Jira was based, the user was trying to write a generic recovery program which would forget transactions that had been heuristically completed and rollback if they were not heuristically completed but rather still in a prepared state. He would first try the forget() and then if that gave an XAER_PROTO would attempt the rollback(). The workaround we gave was to also check for XAER_NOTA.
3) It is interesting to note that for other calls XAER_NOTA has a different description.
XAER_NOTA - The specified XID is not known by the resource manager.
I wish I understood some more about heuristic completion but tend to think that since the only way to differentiate a prepared vs heuristically completed transaction returned by recover() is to call forget, the user was not really calling it in an improper context and someone went out of their way to put that extra condition on the XAER_NOTA exception desription for forget(), so my somewhat uneasy opinion is that XAER_NOTA is most appropriate whenever forget() is called with Derby. Opinions?
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742952#action_12742952 ]
Tiago R. Espinha commented on DERBY-1016:
-----------------------------------------
I have been discussing this issue with Kathey and Myrna on IRC and it is generally hard to reach an optimal behavior, mostly because the XA specification is too vague and not very clear on this issue.
On MySQL for example, we are able to invoke a forget on a transaction right after we start it, whereas this is not possible in DB2. Also, running the attached repro against MySQL makes it fail with XAER_RMFAIL:
XAER_RMFAIL: The command cannot be executed when global transaction is in the ACTIVE state
Still, since we don't have heuristic transactions in Derby, forget will always return an error and never really succeed. This way, we thought the best behavior is to throw XAER_NOTA (not a transaction) whenever the XID doesn't exist and throw XAER_PROTO for all the cases where the XID exists.
Should no one object to this change, I'll create a patch and go through with it.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1016?page=comments#action_12367447 ]
Daniel John Debrunner commented on DERBY-1016:
----------------------------------------------
Reading the javadoc for XAResource I think I agree with you, XAER_PROTO is the correct error.
XAResource.recover()
"The transaction manager calls this method during recovery to obtain the list of transaction branches that are currently in prepared or heuristically completed states."
XAResource.forget
"Tells the resource manager to forget about a heuristically completed transaction branch."
Thus a prepared transaction is not a heuristically completed transaction branch and therefore is not a valid state for forget.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: http://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Type: Bug
> Components: JDBC
> Versions: 10.2.0.0, 10.1.2.3, 10.1.3.0
> Reporter: Kathey Marsden
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ravinder Reddy reassigned DERBY-1016:
-------------------------------------
Assignee: Ravinder Reddy
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: ReproDerby1016.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741105#action_12741105 ]
Myrna van Lunteren commented on DERBY-1016:
-------------------------------------------
I forgot to say - the test case in xaTransactionTest looks good.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Myrna van Lunteren (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740193#action_12740193 ]
Myrna van Lunteren commented on DERBY-1016:
-------------------------------------------
Tiago, maybe the upgrade tests, or not all of them, did get run? Did you maybe run with -DderbyTesting.oldReleasePath set to an old directory? Or perhaps you didn't run with it set and there was a problem getting to 'http://svn.apache.org/repos/asf/db/derby/jars'? (like, either that http server was down or you have some sort of firewall protection or had network trouble).
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (DERBY-1016)
javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of
XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710693#action_12710693 ]
Ravinder Reddy edited comment on DERBY-1016 at 5/19/09 3:48 AM:
----------------------------------------------------------------
I am getting the following error when I try to reproduce the error for DERBY-1016
ReproDerby1016.java:26: cannot find symbol
symbol : class utilXid
location: class ReproDerby1016
Xid xid = new utilXid(1,93,18);
^
1 error
More Info about the Derby Setup:
I have checked-out trunk source in windows machine and built it using Ant.
I have created a lib folder in home directory and copied all jars (jars/sane/*.jar) to lib and set the DERBY_HOME , path , classpath accordingly.
I have put classes folder also in classpath.
what might be the Error.?
was (Author: pandiri):
I am getting the following error when I try to reproduce the error for DERBY-1016
ReproDerby1016.java:26: cannot find symbol
symbol : class utilXid
location: class ReproDerby1016
Xid xid = new utilXid(1,93,18);
^
1 error
More Info about the Derby Setup:
I have checked-out truck source in windows machine and built it using Ant.
I have created a lib folder in home directory and copied all jars (jars/sane/*.jar) to lib and set the DERBY_HOME , path , classpath accordingly.
I have put classes folder also in classpath.
what might be the Error.?
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: ReproDerby1016.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12742663#action_12742663 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
Just to add in another opinion, I consulted with my colleague with the JCC team (DB2) and he feels XAER_PROTO is correct. He said:
"I would say that XAER_PROTO is more appropriate as the resource manager is aware of the XID in prepared state."
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha updated DERBY-1016:
------------------------------------
Attachment: DERBY-1016.patch
I'm attaching a fixed patch. I've also ran suites.All with no failures. However, I ran suites.All under Mac OS X and I was surprised to get a test count that was inferior to 10k tests. If I recall correctly, my Windows and Linux runs always have around 12k tests - is there a logical explanation for this? And is it concerning?
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12711238#action_12711238 ]
Ravinder Reddy commented on DERBY-1016:
---------------------------------------
Thanks Kathey
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Tiago R. Espinha reassigned DERBY-1016:
---------------------------------------
Assignee: Tiago R. Espinha
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Ravinder Reddy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739957#action_12739957 ]
Ravinder Reddy commented on DERBY-1016:
---------------------------------------
Sure , I will be back !
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738687#action_12738687 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
Hi Tiago,
Before you start your suites.All run. The test should use the J2EEDataSource class and run with client too.
Also I think the arguments in the assertEquals are reversed.
XAeForget.errorCode, XAException.XAER_PROTO
The expected code should come first.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Rick Hillegas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Hillegas updated DERBY-1016:
---------------------------------
Issue & fix info: [High Value Fix, Newcomer, Repro attached] (was: [Newcomer, High Value Fix])
Urgency: Normal
Triaged for 10.5.3: assigned normal urgency and noted that a repro is attached.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Ravinder Reddy
> Attachments: DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741501#action_12741501 ]
Kathey Marsden commented on DERBY-1016:
---------------------------------------
I have not looked closely at this issue or the XA spec in a long time, but my gut instinct is that we should still return XAER_PROTO for this case:
(XA)> xa_prepare 1;
ij(XA)> -- can only forget heuristically completed transaction
xa_forget 1;
IJ ERROR: XAER_PROTO <--returns XAER_NOTA after patch
The new behavior seems to contradict the description of the issue: javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XAERR_PROTO on a prepared transaction
and in general you would think that if the transaction exists you shouldn't get XAER_NOTA (no transaction)
Please consult the XA Spec to clarify what the behavior should be.
http://www.opengroup.org/publications/catalog/c193.htm
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Posted by "Tiago R. Espinha (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740201#action_12740201 ]
Tiago R. Espinha commented on DERBY-1016:
-----------------------------------------
It is possible that the upgrade tests were skipped. I didn't use the derbyTesting.oldReleasePath but network trouble isn't completely out of the picture. I will give it another spin today with derby.tests.trace=true and redirecting the output to a file, then maybe I can see which ones were skipped.
I'm just worried that this might be a Mac issue, as Macs run Apple's own JDK. In the meanwhile I'm doing my test runs on my trustworthy Ubuntu VM, just to be safe.
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-1016
> URL: https://issues.apache.org/jira/browse/DERBY-1016
> Project: Derby
> Issue Type: Bug
> Components: JDBC
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assignee: Tiago R. Espinha
> Attachments: DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff, ReproDerby1016.java, utilXid.java
>
>
> javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
> I posted a question to derby-dev about this and heard no response so am assuming it is indeed a bug.
> in the XA+
> specification, it seems like xa_forget should only be valid for a
> heuristically completed transaction, so should be XAER_PROTO
> and not XAER_NOTA.
> In xaStateTran.sql we have this case:
> -- get back into prepared state
> xa_start xa_noflags 50;
> insert into xastate values(2);
> xa_end xa_success 50;
> xa_prepare 50;
> select * from global_xactTable where gxid is not null order by gxid;
> -- the following should error XAER_NOTA
> xa_forget 50;
> The user code I am looking at handles forget like this. They expect
> XAER_PROTO in this case.
>
> try {
> xaRes.forget(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1) + "]
> Forgotten. \n" );
> } catch (XAException XAeForget) {
> if ( XAeForget.errorCode ==
> XAException.XAER_PROTO ) {
> System.out.print("XA-Transaction [" + (i+1)
> + "] not heuristically completed yet - Rolling Back instead. \n" );
> xaRes.rollback(xidList[i]);
> System.out.print("XA-Transaction [" + (i+1)
> + "] Rolled Back. \n" );
> }
> if ( XAeForget.getMessage() != null ) {
> System.out.println("XAException " +
> XAeForget.getMessage() );
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.