1 2 3 Previous Next 35 Replies Latest reply on Sep 28, 2009 9:11 AM by jmesnil

    XA resource and setting the timeout

    ataylor

      Currently in JBM 2 we don't support setting the timeout on an XA Session. Since neither the JTA or XA specs define what a 'timeout' means we need to decide what the semantics of a timeout are with regard to an XA Session.

      A simplistic solution would be to roll back the tx and remove it from the Resource Manager but i'm not sure as to what effect this would have with the tx manager. Maybe one of the tx gurus could comment on what they think the expected semantics are!

        • 1. Re: XA resource and setting the timeout
          ataylor

          The XA spec from the open group says:, " for a commit and prepare: the resource manager did not prepare or commit the work, upon return the resource manager has rolled back the branch and has released all held resources. the value XA_RBTIMEOUT is returned when the work took too long"

          I guess this is the way to handle it?

          • 2. Re: XA resource and setting the timeout
            jhalliday

            The XA spec has this to say on the matter:

            "An RM can mark a transaction branch as rollback-only any time except after a successful prepare. A TM detects this when the RM returns a rollback-only return code. An RM can also unilaterally roll back and forget a branch any time except after a successful prepare. A TM detects this when a subsequent call indicates that the RM does not recognise the XID. The former technique gives the TM more information.


            So your options are: keep some meta data around after the timeout, so that you can reply 'rollback only', or throw away everything and reply 'unknown tx id'. It's up to the tm to deal with either of those cases. I don't off the top of my head know how well JBossTS will respond to either of them. I'm not aware of any major RM that uses either, so I suspect we'll run into seldom exercised corner cases.

            BTW, what's the perceived advantage to you in implementing timeouts at the resource level, given that users will (hopefully) set an overall tx timeout interval if they want one?

            • 3. Re: XA resource and setting the timeout
              timfox

               

              "jhalliday" wrote:

              So your options are: keep some meta data around after the timeout, so that you can reply 'rollback only'


              If we keep some meta data lying around, we may as well just keep the transaction branch and not roll it back. At least that would give the tx mgr the opportunity to commit at some time too. It seems to me timing out without being able to delete the branch state in the RM seems a bit pointless.


              , or throw away everything and reply 'unknown tx id'.


              Seems sensible. At least then we can delete the state.


              BTW, what's the perceived advantage to you in implementing timeouts at the resource level, given that users will (hopefully) set an overall tx timeout interval if they want one?


              Set and getTransactionTimeout are on the xaresource API so would it's my understanding they would be called by the transaction manager?? If the tx mgr does decide to call them, then it's my assumption that we need to implement them in a way that doesn't break anything.

              • 4. Re: XA resource and setting the timeout
                jhalliday

                The transaction manager will pass on any transaction level timeout information to the resource manager, but it's up to the RM to decide what, if anything, to do with that information.

                Since the TM will drive a transaction timeout itself anyhow, the RM does not really need to do anything proactive with the information. It's only worthwhile if you don't trust the TM to come along and rollback the branch in a timely manner. That can happen if the TM and RM are running as separate processes and the TM crashes, but it's not common.

                The utility really depends on your locking model and other resource (in the sense of RAM/disk etc) usage constraints. If releasing resources promptly is important to you then by all means put in your own rollback processing. Otherwise just implement getter/setter for API compliance and do nothing with the information.

                • 5. Re: XA resource and setting the timeout
                  timfox

                  Ok, from a messaging POV the simplest thing for us to do would be to rollback and remove the tx branch on timeout.

                  • 6. Re: XA resource and setting the timeout
                    asimon

                    From the XA Open Group point of view I agree with what Jonathan said. However form the Javax XA API point of view I would say that we have two choices:
                    1) rollback the branch and ignore it (i.e. return XAERR_NOTA) or don't roll it back at all. In this case setTransactionTimeout MUST return false to indicate that the timeout is not handle as expected by the resource
                    2) setTransactionTimeout returns true and this implies that the branch is rolled back and XA_RBTIMEOUT is returned. I.e. we must remember the tx branch ID.

                    Arnaud

                    • 7. Re: XA resource and setting the timeout
                      ataylor

                      Ok, I think the consensus is we roll back the tx, this will clear any acknowledgements or messages. The question is do we remove the tx completely or leave it with the resource manager and return XA_RBTIMEOUT. I think as long as the tm can handle the first case then we should just do that as its simpler.

                      • 8. Re: XA resource and setting the timeout
                        timfox

                         

                        "ataylor" wrote:
                        Ok, I think the consensus is we roll back the tx, this will clear any acknowledgements or messages. The question is do we remove the tx completely or leave it with the resource manager and return XA_RBTIMEOUT. I think as long as the tm can handle the first case then we should just do that as its simpler.


                        Yes, but if Arnaud is right we also need to return false to set timeout.

                        • 9. Re: XA resource and setting the timeout
                          ataylor

                           

                          Yes, but if Arnaud is right we also need to return false to set timeout.

                          even if the transaction timeout was set successfully?

                          • 10. Re: XA resource and setting the timeout
                            timfox

                             

                            "ataylor" wrote:
                            Yes, but if Arnaud is right we also need to return false to set timeout.

                            even if the transaction timeout was set successfully?


                            Yes that's my understanding from reading his post:

                            " In this case setTransactionTimeout MUST return false to indicate that the timeout is not handle as expected by the resource "

                            • 11. Re: XA resource and setting the timeout
                              asimon

                               


                              even if the transaction timeout was set successfully?


                              The problem really is whether you comply wit the javax XA API. So if you accept to set the timeout then you should return XA_RBTIMEOUT and not XAERR_NOTA. As you have decided not to return XA_RBTIMEOUT then setTransactionTimeout should always return false.

                              Arnaud

                              • 12. Re: XA resource and setting the timeout
                                ataylor

                                 

                                The problem really is whether you comply wit the javax XA API. So if you accept to set the timeout then you should return XA_RBTIMEOUT and not XAERR_NOTA. As you have decided not to return XA_RBTIMEOUT then setTransactionTimeout should always return false.


                                Ok, so we don't allow the TM to set the timeout.

                                I'll add a configuration attribute to set the JBM default timeout so we can configure it at a JBM level.

                                • 13. Re: XA resource and setting the timeout
                                  timfox

                                  I'm not sure if I follow the logic here.

                                  If we return false to setTransactionTimeout(), why is it ok to time out transactions ourselves, and return XA_ERNOTA?

                                  • 14. Re: XA resource and setting the timeout
                                    ataylor

                                     

                                    If we return false to setTransactionTimeout(), why is it ok to time out transactions ourselves, and return XA_ERNOTA?


                                    The way I read Arnaud's comment is that if we return true from setTransactionTimeout then the Transaction Manager will expect us to timeout with a XA_RBTIMEOUT after the time set. Since we we will be returning XA_ERNOTA we need to return false.

                                    1 2 3 Previous Next