Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1089295098.1250028135108.JavaMail.jira@brutus>
Date: Tue, 11 Aug 2009 15:02:15 -0700 (PDT)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-1016) javax.transaction.xa.forget (Xid)
 raises XAER_NOTA exception instead of XA_PROTO on a prepared transaction
In-Reply-To: <353482326.1140545362120.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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.