8 Replies Latest reply on Jul 21, 2008 10:40 AM by Brice Ruth

    Ws-Tx bridge creates JTA transaction, cannot join?

    Brice Ruth Novice

      It appears that the ws-tx bridge, as currently written, needs to start before anything else in the thread sets up a JTA transaction. Is it a technical limitation that the bridge needs to be "first", or just a limitation of the bridge code as its currently written? I have just noticed that I need to be mindful of where the bridge is initiated, with respect to the spring-tx demarcation, otherwise I get an exception indicating that a transaction already exists.

      Thanks,
      Brice

        • 1. Re: Ws-Tx bridge creates JTA transaction, cannot join?
          Jonathan Halliday Master

          That's by design. Best bet is to hook it into the WS interceptor chain so your application code does not need to bother about it.

          • 2. Re: Ws-Tx bridge creates JTA transaction, cannot join?
            Brice Ruth Novice

            Yep, that's what we do on the service side, (for incoming connections) but on the client side, we are also bridging our outgoing service calls to our local JTA transaction. What I've done now is create an Interceptor that I wire in with Spring, but I found I have to be careful of the order, because the same bean can (is) surrounded by the Spring standard transaction advice for Hibernate, and that currently needs to execute *after* the bridge is started.

            I think when Paul R. was here working with us (back in October '07) to get the ws-tx and bridging to work, you had mentioned that client-side bridging was not originally intended for the bridge code (but, we got it to work, and its working fabulously so far).

            Thanks for the quick response!

            • 3. Re: Ws-Tx bridge creates JTA transaction, cannot join?
              Jonathan Halliday Master

              The way to think about this is: the JTA transaction needs to be subservient to the WS-AT transaction. When e.g. an EJB container starts a new JTA transaction, it's always top level rather than subservient. Only the bridge creates the JTA transaction in the right way for this usage scenario. Hence it has to come before any interceptors that check for a running transaction and start a new one if necessary.

              This is unfortunately a bit of a configuration nightmare, particularly with e.g. EJBs exposed as Web Services using @WebService. It would be nice if there were a way to take an existing top level JTA transaction and transform it into a subservient one, but there isn't.

              • 4. Re: Ws-Tx bridge creates JTA transaction, cannot join?
                Brice Ruth Novice

                 

                "jhalliday" wrote:
                The way to think about this is: the JTA transaction needs to be subservient to the WS-AT transaction. When e.g. an EJB container starts a new JTA transaction, it's always top level rather than subservient. Only the bridge creates the JTA transaction in the right way for this usage scenario. Hence it has to come before any interceptors that check for a running transaction and start a new one if necessary.

                This is unfortunately a bit of a configuration nightmare, particularly with e.g. EJBs exposed as Web Services using @WebService. It would be nice if there were a way to take an existing top level JTA transaction and transform it into a subservient one, but there isn't.


                Alright. We'll categorize this under "technical limitation" :-) We'll just need to make sure Mark includes "subservient" transaction coersion in the next version of the JTA spec ;-)

                • 5. Re: Ws-Tx bridge creates JTA transaction, cannot join?
                  Jonathan Halliday Master

                  JTA does not really have any notion of subtransactions, largely because no major XA Resource manager supports them. If I has an infinite amount of free time I'd like to put subtransaction support into one of the pure java embedded databases, such as hsqldb. But first we need subtransactions in XTS, so that we can write the reverse direction of the bridging...

                  • 6. Re: Ws-Tx bridge creates JTA transaction, cannot join?
                    Brice Ruth Novice

                     

                    "jhalliday" wrote:
                    JTA does not really have any notion of subtransactions, largely because no major XA Resource manager supports them. If I has an infinite amount of free time I'd like to put subtransaction support into one of the pure java embedded databases, such as hsqldb. But first we need subtransactions in XTS, so that we can write the reverse direction of the bridging...


                    What would subtransactions provide in XTS? I'm not sure I follow that. That's something different from having nested coordinators, obviously (since that's provided today). Would subtransactions be the ability for a WS-AT to be a part of a parent Tx (such as a JTA Tx)? Right now the bridge sets up the WS-AT and makes the JTA a participant of it, right?

                    • 7. Re: Ws-Tx bridge creates JTA transaction, cannot join?
                      Mark Little Master

                      Subtransactions == nested transactions (Eliot Moss, 1981).

                      "nested coordinator" is more accurately interposition of coordinators. Check out the OTS specification (circa 1992).

                      • 8. Re: Ws-Tx bridge creates JTA transaction, cannot join?
                        Brice Ruth Novice

                         

                        "mark.little@jboss.com" wrote:
                        Subtransactions == nested transactions (Eliot Moss, 1981).

                        "nested coordinator" is more accurately interposition of coordinators. Check out the OTS specification (circa 1992).


                        Ah, correct. See, its been like 9 months since Paul R.'s training session and the cobwebs are starting to set in ;-)