db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-1016) javax.transaction.xa.forget (Xid) raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
Date Wed, 30 Nov 2011 06:09:39 GMT

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

Myrna van Lunteren commented on DERBY-1016:

Thanks Jayaram for that patch.

There are a couple of concerns with your patch.
Firstly, the .stat file seems to list a number of files that have conflicts. 
Secondly, there were some unnecessary whitespace differences, some unnecessary brackets, and
there were some left-over references to java.io.PrintStream - probably from some debugging
Usually, before submitting a patch, it makes sense to review your svn diff result and carefully
evaluate your changes...

Apart from that, the patch looked fine to me.
However, it seems that the forget method in EmbedXAResource that was changed for this test
would return either an XAER_NOTA or XAER_PROTO, and so perhaps it would be nice to have an
additional test case for the XAER_NOTA.
I've uploaded a patch that makes those minor adjustments.

However, I have two further questions:
- before submitting this latest patch, you mentioned seeing the test fail. What happened between
then and now? Did the problem get resolved by doing a clean build (after ant clobber) perhaps?
- Did you run suites.All?

I ran jdbcapi._Suite which I think is enough to test the latest patch. That patch is now ready
for review.
> 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:,
>            Reporter: Kathey Marsden
>            Assignee: Jayaram Subramanian
>              Labels: derby_triage10_5_2
>         Attachments: DERBY-1016.diff, DERBY-1016.patch, DERBY-1016.patch, DERBY-1016_Patch_1.diff,
ReproDerby1016.java, derby1016-donotcommit.diff, derby1016-stat.txt, runoutputNov30.out, 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message