Announcement Announcement Module
Collapse
No announcement yet.
Transaction Management in Spring-Integration framework Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Transaction Management in Spring-Integration framework

    I'm browsing Integration frameworks to choose the best one for my integration problem. one thing that I want to know is transaction management in multiple application integration context, supported or not ? and if it does, how ? in Pro Spring Integration I didn't find a clear solution they just put sth like

    Code:
    <int:poller fixed-rate="1000">
    <int:transactional/>
    </int:poller>
    and I couldn't understand how this manage transaction along multiple application ?

    could anyone expert in these frameworks help me to find out to know that how transaction management and recovery in case of error in any application that transaction is executing can be done using these frameworks ? for example consider this scenario : application A initiate transaction and use applications B and C in middle and finally do sth after B and C and commit it, if in this scenario application c fails or throw an exception, is there anyway to rollback transaction in B and A and how ?

  • #2
    When you said multiple application contexts, do also mean they are not executing on the same Virtual machine and are remote to each other? Can you explain your use case in more details?

    To answer your question if invocations on beans from different application context can be executed in one transaction? Yes, it is possible but will need to know your use case for that.

    Comment


    • #3
      Originally posted by Amol Nayak View Post
      When you said multiple application contexts, do also mean they are not executing on the same Virtual machine and are remote to each other? Can you explain your use case in more details?
      Yes. I mean remote to each other and multiple applications even may using different technologies or spring-integration.
      Last edited by iramin; Mar 4th, 2012, 02:17 AM.

      Comment


      • #4
        As far as transaction manager is concerned, JTA transaction manager is what you need to use for sure.
        How are you planning to perform communication between these remote applications? If you use HTTP or even JMS for communication, you cannot pass the transaction context from one node to another.
        I feel you giving some more details about the application you want to design can help narrow down the suggestions.

        Comment


        • #5
          Originally posted by Amol Nayak View Post

          To answer your question if invocations on beans from different application context can be executed in one transaction? Yes, it is possible but will need to know your use case for that.
          my scenario is sth like this :
          Code:
          confirmScenario(T entity){
          
          localBean.validate(entity);
          localBean.process(entity);
          legacySystemA.validate(entity);
          legacySystemB.process(entity);
          externalPaymentService.doPayment(entity);
          .
          .
          .
          
          }
          I want to know is there anyway to make this scenario transactional ?
          communication with external systems is almost with Web Service, but in case of communication with our legacy systems we haven't decided yet, if special communication way such as JMS can help us and Web Service doesn't, we can use those communication methods.
          Last edited by iramin; Mar 4th, 2012, 02:37 AM.

          Comment


          • #6
            Based on what i see, validate possibly just validates some records and perhaps does not affect the state if the entity, the process method localBean and legacySystemB needs to succeed when the doPayment runs successfully else both needs to rollback. Is my understanding correct?

            For this to happen, the resource adapter of your legacy system should be XA compliant and can participate in a distributed transaction. I don't know what your localBean does, but if it is some kind of database operation, it should not be a problem.

            If your legacy system is XA compliant, then JTA transaction manager is what you need to use.

            Comment


            • #7
              You cannot use JMS for communication as the transaction on client will just ensure sending of the message to the queue, the remote operation that happens after the message is picked up by the receiver and processed will not be a part of the transactions initiated by the client.
              EJBs however do support propagation of the transaction context.

              Comment


              • #8
                Originally posted by Amol Nayak View Post
                Based on what i see, validate possibly just validates some records and perhaps does not affect the state if the entity, the process method localBean and legacySystemB needs to succeed when the doPayment runs successfully else both needs to rollback. Is my understanding correct?

                For this to happen, the resource adapter of your legacy system should be XA compliant and can participate in a distributed transaction. I don't know what your localBean does, but if it is some kind of database operation, it should not be a problem.

                If your legacy system is XA compliant, then JTA transaction manager is what you need to use.
                thanks for your help. I think I need these requirements.
                can you provide me some links or tutorials for using transaction managers in such a scenario that work with multiple applications for example using Web Services?
                Last edited by iramin; Mar 4th, 2012, 03:06 AM.

                Comment


                • #9
                  Originally posted by Amol Nayak View Post
                  Based on what i see, validate possibly just validates some records and perhaps does not affect the state if the entity, the process method localBean and legacySystemB needs to succeed when the doPayment runs successfully else both needs to rollback. Is my understanding correct?

                  For this to happen, the resource adapter of your legacy system should be XA compliant and can participate in a distributed transaction. I don't know what your localBean does, but if it is some kind of database operation, it should not be a problem.

                  If your legacy system is XA compliant, then JTA transaction manager is what you need to use.
                  if communication with other application is implemented by Web Service, does transaction can be handled by XA protocol ?

                  Comment


                  • #10
                    Some transaction managers like Jboss's transaction manager or Atomikos do. Infact atomikos also provides propagation of transaction over JMS (but you need to use a Non XA JMS adapter)
                    But I haven't used any of these personally so can't make any suggestions.

                    Comment


                    • #11
                      Hi,

                      Just wanted to mention it - As an alternative (depending on your specific requirements), you might also want to consider using "Compensating Transactions" instead of distributed transactions.

                      http://www.infoq.com/articles/ebay-s...best-practices

                      http://en.wikipedia.org/wiki/Compensating_transaction

                      Cheers,

                      Gunnar

                      Comment


                      • #12
                        I'd also highly recommend reading this article: http://www.javaworld.com/javaworld/j...nsactions.html

                        One thing you'll notice is that the Spring Framework provides flexibility to use just about any transaction strategy you want, and since Spring Integration builds directly upon the underlying framework, the same options are available within a Spring Integration app.

                        Hope that helps.
                        -Mark

                        Comment

                        Working...
                        X