5 Replies Latest reply on Mar 14, 2006 7:52 AM by Mark Little

    Checked Transactions (Phorum)

    Mark Little Master

      Author: Anton
      Date: 09-28-04 18:00

      I'm evaluating the checked transaction behaviour of ATS.

      I read the Programmers Guide and therefore should fulfill all described requirements:
      *OTS_CHECKED_TRANSACTION property
      *co-located transaction manager
      *implicit transaction propagation

      I also wrote a little example:
      During an active transaction, I asynchronously start a new thread, call resume (otherwise the new thread is not associated with the transaction) and terminate the transaction while the thread is still active. In this case, I get the corresponding warning. So everything works as expected.

      For my work, however, I need two (or more) loosely coupled processes to perform work within the same distributed transaction.
      The first process starts a transaction and passes the control object's reference to the other process, which can subsequently resume the transaction and participates. Finally the first process terminates the transaction.
      The example also works, but in this case there is no checked transaction behaviour. If the transaction terminates, while the second process has not finished its work, there is no corresponding warning.

      I think it should be possible to have checked transactions between different processes, isn't it?. What else could be the reason for this malfunction?

        • 1. Re:  Checked Transactions (Phorum)
          Mark Little Master

          Author: Mark Little
          Date: 09-28-04 21:37

          How do you pass the transaction reference between your two processes?

          Mark.

          • 2. Re:  Checked Transactions (Phorum)
            Mark Little Master

            Author: Anton
            Date: 09-29-04 09:59

            I already tried two ways to pass the IOR of the Control object:
            1) Writing the reference to a file or
            2) sending it within a notification

            The example looks like the following:

            First process:
            Current current = OTSManager.get_current();
            current.begin();
            // do some transactional work here
            org.omg.CORBA.Object obj = current.get_control();
            String ControlString = myORB.orb().object_to_string(obj);
            // pass the reference (file or notification)
            // wait a little bit to be sure that the second process is able to
            // receive the reference and calls resume()
            current.commit();

            Second process:
            // get the reference (from file or notification)
            Current current = OTSManager.get_current();
            org.omg.CORBA.Object obj = myORB.orb().string_to_object(ControlString);
            Control c = ControlHelper.narrow(obj);
            current.resume(c);
            // wait a little bit to be sure that the first process calls commit :-)
            // try to do some transactional work here

            At this point, the originator has already committed the transaction and the second process can not perform its transactional work, throwing a lot of
            java.net.ConnectExceptions. It seems that ATS is trying to reconnect a few times and finally gives up.
            I forgot to mention, that the two processes are in different JVMs.

            However, if I make the first process wait for the second one to finsih its work, the transaction terminates correctly (even if in the case of a rollback)


            • 3. Re:  Checked Transactions (Phorum)
              Mark Little Master

              Author: Mark Little
              Date: 09-29-04 12:31

              Anton wrote:

              > I already tried two ways to pass the IOR of the Control
              > object:
              > 1) Writing the reference to a file or
              > 2) sending it within a notification
              >
              > The example looks like the following:
              >
              > First process:
              > Current current = OTSManager.get_current();
              > current.begin();
              > // do some transactional work here
              > org.omg.CORBA.Object obj = current.get_control();
              > String ControlString = myORB.orb().object_to_string(obj);
              > // pass the reference (file or notification)
              > // wait a little bit to be sure that the second process is
              > able to
              > // receive the reference and calls resume()
              > current.commit();
              >
              > Second process:
              > // get the reference (from file or notification)
              > Current current = OTSManager.get_current();
              > org.omg.CORBA.Object obj =
              > myORB.orb().string_to_object(ControlString);
              > Control c = ControlHelper.narrow(obj);
              > current.resume(c);
              > // wait a little bit to be sure that the first process calls
              > commit :-)
              > // try to do some transactional work here
              >
              > At this point, the originator has already committed the
              > transaction and the second process can not perform its
              > transactional work, throwing a lot of
              > java.net.ConnectExceptions. It seems that ATS is trying to
              > reconnect a few times and finally gives up.
              > I forgot to mention, that the two processes are in different
              > JVMs.
              >
              > However, if I make the first process wait for the second one
              > to finsih its work, the transaction terminates correctly (even
              > if in the case of a rollback)

              As the ATS manual and the OTS specification says, checked transaction semantics are not supported for explicit context propagation.

              One thing you might want to try is to get your second thread to register a synchronization with the transaction when it first receives it. Have the before_completion method block until the second thread has finished. It's crude, but it will work.

              Mark.

              • 4. Re:  Checked Transactions (Phorum)
                Mark Little Master

                Author: Anton
                Date: 09-29-04 18:10

                Mark Little wrote:
                > As the ATS manual and the OTS specification says, checked
                > transaction semantics are not supported for explicit context
                > propagation.
                >
                > One thing you might want to try is to get your second thread
                > to register a synchronization with the transaction when it
                > first receives it. Have the before_completion method block
                > until the second thread has finished. It's crude, but it will
                > work.

                In my application, the two processes are loosely coupled and don't communicate directly. Therefore the second process doesn't know anything about the transaction and the context has to be propagated explicitly.

                It seems that I can't have checked transaction between these processes, unless I try to register a synchronization, as you suggested (thank you for this hint) Another possibility is to I find a way to implicit propagate the context.


                Finally, I'm a little bit surprised that my first example with checked transaction works, because its very similar to the one described above:
                I start a new Thread within a transaction. I also have to call resume on the Thread, because I don't use the special OTS_Thread class and without it the new Thread would not get associated automatically.

                So I also have to pass the Control object as a parameter to the Threads constructor. This looks very similar to explicit context propagation. The only difference is, that in the first case the threads are in different JVMs, whereas in the second case they are in the same JVM.

                • 5. Re:  Checked Transactions (Phorum)
                  Mark Little Master

                  Author: Mark Little
                  Date: 09-29-04 20:53

                  > > As the ATS manual and the OTS specification says, checked
                  > > transaction semantics are not supported for explicit
                  > context
                  > > propagation.
                  > >
                  > > One thing you might want to try is to get your second
                  > thread
                  > > to register a synchronization with the transaction when it
                  > > first receives it. Have the before_completion method block
                  > > until the second thread has finished. It's crude, but it
                  > will
                  > > work.
                  >
                  > In my application, the two processes are loosely coupled and
                  > don't communicate directly. Therefore the second process
                  > doesn't know anything about the transaction and the context has
                  > to be propagated explicitly.

                  The traditional checked transaction models, e.g., the one defined by X/Open XA, simply won't work in that situation. The problem is that in order to do checking at the low-level, the transaction system must know who has the context. If you pass it explicitly, then that passing can't be intercepted and "recorded" in order to do this tracking.

                  > It seems that I can't have checked transaction between these
                  > processes, unless I try to register a synchronization, as you
                  > suggested (thank you for this hint) Another possibility is to I
                  > find a way to implicit propagate the context.

                  I'd suggest you stick with the Synchronization approach. If these are really loosely coupled processes then it's better to do the checking at the "application" level.

                  > Finally, I'm a little bit surprised that my first example
                  > with checked transaction works, because its very similar to the
                  > one described above:
                  > I start a new Thread within a transaction. I also have to
                  > call resume on the Thread, because I don't use the special
                  > OTS_Thread class and without it the new Thread would not get
                  > associated automatically.
                  >
                  > So I also have to pass the Control object as a parameter to
                  > the Threads constructor. This looks very similar to explicit
                  > context propagation. The only difference is, that in the first
                  > case the threads are in different JVMs, whereas in the second
                  > case they are in the same JVM.

                  Co-located sharing of transactions is slightly different. In that case, we can keep track of who's got the context because we know about the threads in the VM.

                  Also remember that with ATS you can register your own checking object (CheckedAction) for each transaction is that helps.

                  Mark.