1 2 Previous Next 22 Replies Latest reply on Sep 11, 2007 10:24 AM by marklittle Go to original post
      • 15. Re: Is there one-phase commit in WS-AT?
        jhalliday

        The map not only has to be durable (extra disk writes - yuck) but also shared - two app servers receiving the same WS-AT context must map to different branches of the same global tx if they are going to connect to the same resource manager, otherwise they may block each other. It would be way easier if the mapping information was contained in the wire context itself, rather than requiring all that extra plumbing.

        • 16. Re: Is there one-phase commit in WS-AT?
          marklittle

          Hmmm, all the things we do within our distributed transactions implementations anyway ;-) Even with the OTS this is necessary: OTS only defines a global transaction id and says absolutely nothing about the branch qualifier because it can't: it's a TM, not an RM. Whether you do a START, a JOIN or a RESUME is not the domain of the transaction manager. That is the RM part of the contract.

          • 17. Re: Is there one-phase commit in WS-AT?
            marklittle

             

            "jhalliday" wrote:
            The map not only has to be durable (extra disk writes - yuck)


            It has to be durable, but how you do that is an implementation choice. If you want to do it through an extra disk write then fine, but I wouldn't recommend it. We certainly don't do it that way.

            • 18. Re: Is there one-phase commit in WS-AT?
              reverbel

               

              "mark.little@jboss.com" wrote:
              Why would they be different global ids?

              Because there is no standard way of converting the global id from the URI format (which is what each AS/TM receives) to the pair <formatId, globalIdByteArray> that the RM will receive within an Xid. If the appservers are from different vendors, their TMs will probably pick different formatIds. Moreover, if the URI does not fit into the 64-byte space of the globalIdByteArray, the TMs are also likely to pass different byte arrays to the RM.

              The transaction id is defined by the coordinator and is returned in response to a begin request. In your example the user application would propagate the same TxId to both AS instances.

              Right. The problem is getting the same TxId to the RM through both branches. The appservers/TMs would have to agree on a way of converting the URI TxId to a pair <formatId, globalIdArray>.

              Since neither instance needs to know about the other, in all likelihood they'll both attempt to do a START and one of them will get an error.

              No, as both appservers/TMs will probably pick unrelated Xids.

              What we would like to see, of course, is the appservers/TMs picking Xids with the same values in the formatId and globalIdArray fields, but different branch qualifiers. Because the branck qualifiers would be different, both appservers should be able to do a START without getting an error.

              ... create a new interposed Xid using the global TxId from WS-AT as the key in a durable map of some kind.

              I do not see why you want an interposed Xid here.


              • 19. Re: Is there one-phase commit in WS-AT?
                reverbel

                 

                "jhalliday" wrote:
                The map not only has to be durable (extra disk writes - yuck) but also shared - two app servers receiving the same WS-AT context must map to different branches of the same global tx if they are going to connect to the same resource manager, otherwise they may block each other.

                Precisely. Aren't we all in agreement that this is highly unpractical? A durable map, shared between appservers from diferent vendors...

                It would be way easier if the mapping information was contained in the wire context itself, rather than requiring all that extra plumbing.

                Yes. The formatId and the globalIdByteArray should be in the transaction context.



                • 20. Re: Is there one-phase commit in WS-AT?
                  marklittle

                   

                  "reverbel" wrote:
                  "mark.little@jboss.com" wrote:
                  Why would they be different global ids?

                  Because there is no standard way of converting the global id from the URI format (which is what each AS/TM receives) to the pair <formatId, globalIdByteArray> that the RM will receive within an Xid. If the appservers are from different vendors, their TMs will probably pick different formatIds.


                  I'd expect them to definitely pick different formatIds ;-)

                  Moreover, if the URI does not fit into the 64-byte space of the globalIdByteArray, the TMs are also likely to pass different byte arrays to the RM.


                  I already said that we could have defined a standard representation. But then I also pointed out why this wasn't a priority for the standards committee.


                  The transaction id is defined by the coordinator and is returned in response to a begin request. In your example the user application would propagate the same TxId to both AS instances.

                  Right. The problem is getting the same TxId to the RM through both branches. The appservers/TMs would have to agree on a way of converting the URI TxId to a pair <formatId, globalIdArray>.


                  Agreed. Like I said: we could have, but we didn't. Same as we didn't go far with formatIds in OTS, when we could have ...


                  Since neither instance needs to know about the other, in all likelihood they'll both attempt to do a START and one of them will get an error.

                  No, as both appservers/TMs will probably pick unrelated Xids.

                  What we would like to see, of course, is the appservers/TMs picking Xids with the same values in the formatId and globalIdArray fields, but different branch qualifiers. Because the branck qualifiers would be different, both appservers should be able to do a START without getting an error.


                  Well it's quite lucky that so far all the vendors who have done interop have taken then own valid global id structure into the tx URI. So although not standards (and may change), you can take a tx URI and stuff it into a global id and it'll work (tm).


                  ... create a new interposed Xid using the global TxId from WS-AT as the key in a durable map of some kind.

                  I do not see why you want an interposed Xid here.


                  Using the above (undocumented) feature of all of the current WS-AT implementations, you've got a valid global id and all you need to is manufacture a branch qualifier. I didn't mean interposition in the case of proxy coordinator. I meant in the case of a proxy id for the inflowed transaction id.

                  • 21. Re: Is there one-phase commit in WS-AT?
                    marklittle

                     

                    "reverbel" wrote:
                    "jhalliday" wrote:
                    The map not only has to be durable (extra disk writes - yuck) but also shared - two app servers receiving the same WS-AT context must map to different branches of the same global tx if they are going to connect to the same resource manager, otherwise they may block each other.

                    Precisely. Aren't we all in agreement that this is highly unpractical? A durable map, shared between appservers from diferent vendors...

                    It would be way easier if the mapping information was contained in the wire context itself, rather than requiring all that extra plumbing.

                    Yes. The formatId and the globalIdByteArray should be in the transaction context.


                    I agree that we *could* have done that. We didn't because it wasn't a priority. As I already mentioned, XA wasn't the only use case we had to consider when developing the specifications. It would certainly have been wrong to tie WS-AT to XA only. But yes (and for the last time), if someone had raised the issue at the time we could have defined an XID format within the WS-TX committee.

                    As a slight aside, we did have a similar discussion within WS-CAF (which, even though I'm a co-author on both sets of specs, I still think is technically superior to WS-TX) and agreed that it wouldn't be the domain of the technical committee to impose those kinds of formats. Something like IANA. The reason for that is simply process: OASIS and its technical committees aren't set up to efficiently manage this kind of identifier mapping. Each time you rev-ed the id you'd need to rev the specs, which is a major undertaking.

                    That's the same result we came up with in OTS when looking at the formatID in the context. O for OSI TP and ... what ... for something else? OMG doesn't manage those numbers either. IANA was supposed to, but no one really bothered pushing that. It hasn't been a priority because it's always possible to do something along the lines we've mentioned in your implementation. And the cost-benefit trade-off of that versus going to a standards body to agree on an numberical value, is often too much for large companies to bother with. And that's a shame to be honest.

                    • 22. Re: Is there one-phase commit in WS-AT?
                      marklittle

                      Oh and let's not forget: we have done interoperability between IBM, MSFT, IONA and JBoss/Arjuna, with XA in the picture in several cases (though not all because it wasn't an explicit part of the interoperability scenarios). So yes, it's a hassle over an agreed format, but it doesn't prevent the protocol from working across heterogeneous implementations.

                      1 2 Previous Next