6 Replies Latest reply: Mar 20, 2013 9:12 AM by 997957 RSS

    Second transaction in the background in an EJB3 application?

    997957
      Hi!

      Is there any way (preferrably with container-managed persistence, but even manually) to implement 2 transactions in EJB3 that fullfil the following criteria:


      a)
      pseudo-code:

      T1 {
      doSomething1
      start T2 in background
      doSomething2
      commit
      }

      T2 {
      doSomething
      commit
      }


      b)
      conditions: T2 "depends" on T1 in the sense that

      1. T2 starts during T1
      2. if T1 is rolled back ==> T2 must be rolled back, too
      (==> this implies: T2 ends after T1 OR T2 waits for T1 to finish before committing)
      3. if T2 is rolled back ==> doesn't cause T1 to rollback


      c)
      graphically: (intended for viewing with a fixed-width font)
      ("_" = "commit", "." = waiting)
      T1
      [ ]
      [ ]---> T2
      [_]     [ ]
              [_]
      
      OR
      
      T1
      [ ]
      [ ]---> T2
      [ ]     [ ]
      [ ]     [ ]
      [ ]      .
      [ ]      .
      [_]      _
      The hardest part seems to me to make T2 wait until T1 finishes (in the otherwise unlikely but possible case that T1 finishes first). You can safely presume that the two transactions run on the same JVM, but of course a solution that doesn't rely on this presumption would be even better.

      I have tried to find ways for T2 to somehow monitor T1, but on my first half-hearted try I couldn't find anything.



      Any ideas?

      Thanks,
      Agoston

      Edited by: 994954 on Mar 19, 2013 11:36 PM
        • 1. Re: Second transaction in the background in an EJB3 application?
          gimbal2
          2. if T1 is rolled back ==> T2 must be rolled back, too
          I don't think that's possible, the nested transaction is going to be isolated. Otherwise what would be the point of creating it!
          The hardest part seems to me to make T2 wait until T1 finishes
          Implying that T2 is created in a different thread, otherwise T1 would be suspended until T2 finishes in a normal container managed transaction environment. Why thread them when it matters in which order they finish?
          I have tried to find ways for T2 to somehow monitor T1, but on my first half-hearted try I couldn't find anything
          Perhaps because you've been looking in the context of EJB technology, while you should have been researching 'java concurrency'.
          • 2. Re: Second transaction in the background in an EJB3 application?
            r035198x
            gimbal2 wrote:
            >
            Why thread them when it matters in which order they finish?
            Good question.
            • 3. Re: Second transaction in the background in an EJB3 application?
              997957
              Here's the reason: originally it looked like this:

              T1 {
              code A
              code B
              code C
              }

              where code B turned out to take quite long, so we want to run it in the background. It does some sort of logging/auditing, which is not crucial to succeed for the whole operation to succeed, but it shouldn't log anything if the operation is unsuccessful.
              ==> that's where the conditions above are coming from.

              Naturally, this would be the easiest solution:

              run T1, then start T2 in the background, where

              T1 {
              code A
              code C
              }

              T2 {
              code B
              }

              The problem is, code B strongly depends on code A, so it would require quite a bit of refactoring. I've been wondering if that can be avoided.

              So, the question still stands: is the original scenario possible or not?
              • 4. Re: Second transaction in the background in an EJB3 application?
                gimbal2
                gimbal2 wrote:
                2. if T1 is rolled back ==> T2 must be rolled back, too
                I don't think that's possible, the nested transaction is going to be isolated. Otherwise what would be the point of creating it!
                • 5. Re: Second transaction in the background in an EJB3 application?
                  r035198x
                  If C doesn't need results of B then run A, and C and invoke B asynchronously as the last step.
                  • 6. Re: Second transaction in the background in an EJB3 application?
                    997957
                    "The problem is, code B strongly depends on code A, so it would require quite a bit of refactoring. I've been wondering if that can be avoided."

                    As for
                    "I don't think that's possible, the nested transaction is going to be isolated. Otherwise what would be the point of creating it!"

                    ==> yes, I've read that, but I'm still sort of hoping that someone does come up with a solution...
                    The point of creating the second transaction is to carry out some long-running job depending on (==> can't be QUITE isolated), but in case of an error not canceling (==> must be isolated to some extent) the first one.