Announcement Announcement Module
Collapse
No announcement yet.
Transactions & Expections usage between Services. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Transactions & Expections usage between Services.

    Hi,

    sorry if this is not right forum to post this question.

    In one of my client's application I see this exception many times "Caused by: javax.resource.ResourceException: Transaction is not active:"

    We are using spring 2.0.8, Hibernate, Jboss Application Server. Here is the scenario where we are seeing this exception.

    We have two spring services, service A and service B both are Transactional with REQUIRED and set to rollback on RuntimeException.

    Service A calls a method of Service B and in service B execution it throws exception we catch this exception in Service A and continue with executing the remaining method of Service A. So after catch block when ever we try to DB Operation or JMS connection Jboss throws above exception.

    I understand Service A and service B both were running in same transaction so when service B throwed exception transaction was set to roll back and according to JBoss documentation they throw above exception while requesting for Transactional Resource when transaction is set to rollback.

    In my case service A is the one who decides if he should continue or not when there is a exception from service B call and this kind of scenario is used heavily in this application. So Now my question is how should we design our services to solve this kind of issues.

    I had couple of thoughts in mind:
    --> Service A always calls helper services which are not transactional. So even if there is exception in service B transaction is not set to roll back.
    --> Use spring property by which Service A can control commit/rollback of the transaction (but I read in other post this is not good thing to do).

    Please let me know if you need any more information.
    Last edited by rMedishetty; Jun 25th, 2010, 01:22 PM. Reason: changing heading

  • #2
    Well either make the call to service B in a new transaction (this way it doesn't influence your other transaction) or do manual transaction management.

    Comment


    • #3
      I don't want to introduce manual Transaction Management as this will cause more confusion and I want both services to be executed in one Transaction context.

      I was thinking of designing Such that Service A always calls other Services which are non-transactional will solve the problem. Something like for service B I will have service helperB which is not transactional and I will use this in Service A and service B will be used when we are calling from web/external clients. Does that make sense or is it not the right way of doing it.

      Comment


      • #4
        Well using a non-transactional instance could be a solution, however you would have to make sure that there is NO transactional proxy around there, as soon as there is the tx will be marked as rollback only (due to the passing trough the tx advice).

        Comment


        • #5
          How about creating two versions of service B? One that is transactional and one, that isn't. The non-transactional variant should be invoked from transactional services only. Because of Spring's transaction management, all transactional resources will recognize the transaction started with service A. The transactional version of service B is the one used for all other invocations.
          When using old-fashioned XML configuration, this solution just adds a few lines, i.e. a transaction proxy for the non-transactional version.

          HTH

          Comment


          • #6
            Thanks for your response.

            I'm was also thinking of having two flavors of service B one which is transactional and one which is non-transaction, this will solve my problem.

            But this will increase dependency on development team, now they should be aware of which service(Tx/Non-Tx) to choose while injecting. I tested the same scenario with EJB's and they also show the same behavior.

            So, I was just wondering what is the general design guidelines while using services like this.

            Comment


            • #7
              Well, if that's a problem for the development team, there is still another solution from the good old EJB days: facades.
              All services would be non-transactional. For methods, that are invoked from the outside (controllers, web services etc.) you create a facade, which in turn invokes the service like a proxy. The facade would be transactional.

              HTH

              Comment


              • #8
                Session Facade would be a good solution,
                Thanks.

                Comment

                Working...
                X