What really happens when you say utx.begin () ??


EJB design: What really happens when you say utx.begin () ??

  1. I have a problem where my client app is responsible for managing transactions, but I have to make it firewall friendly. My solution is to have the client app write https to a servlet running behind the firewall.

    The problem is when it comes to transactions. The way I'm thinking of doing it is to let the servlet get the utx object via jndi and return it the the client via http, so the client can call utx.begin() and utx.commit(). Is this possible? I'm not sure what utx.begin() really does; does it make a direct connection to the app server? It seemed to me that at least utx.rollback() makes a direct connection to the server as it immediately rolls back the transaction.

    If it makes a direct connection to the server then returning a utx object from the servlet will not work.

  2. By the way I'm using WebLogic 5.1. When I tried the above method I'm getting an error when doing utx.begin():

    javax.transaction.SystemException: java.lang.NullPointerException:
            at weblogic.rjvm.RJVMManager.initialize(RJVMManager.java:79)
            at weblogic.rjvm.RJVMManager.getRJVMManager(RJVMManager.java:67)
            at weblogic.service.BasicReplicaHandler.isHostUnresponsive(BasicReplicaH
            at weblogic.service.BasicReplicaHandler.loadBalance(BasicReplicaHandler.
            at weblogic.service.BasicServiceStub._wl_loadBalance(BasicServiceStub.ja
            at weblogic.service.BasicServiceStub._wl_autoLoadBalance(BasicServiceStu
            at weblogic.jts.internal.CoordinatorFactoryImpl_ServiceStub.createCoordi
            at weblogic.jts.internal.TxContext.getCoordinator(TxContext.java:132)
            at weblogic.jts.internal.TxContext.begin(TxContext.java:84)
            at weblogic.jts.internal.CurrentImpl.begin(CurrentImpl.java:49)

  3. To answer your question about passing transactions across HTTP...

    Absolutely, categorically, NOT!

    You know when you go to a web site and buy something, then you put in your credit card details, and they have big signs saying "ONLY PRESS THE SUBMIT BUTTON ONCE. IF YOU PRESS IT TWICE YOUR CARD COULD BE CHARGED TWICE" etc etc.

    Well, that's precisely because you can't propogate transactions across HTTP, or HTTPS. The reason is as follows.

    HTTP(S) is stateless. The connection isn't persistent, and there is no reliable way for the server to detect when the client goes away (which it absolutely must do if it's going to roll back the transaction.) It will only realize when it tries to write something back over HTTP and finds that you've gone away!

    There is no good way I've seen to do this over HTTP. I would absolutely love it if someone would post to this thread and tell me I have it all wrong and here's how to do it, but I don't think I'm that lucky!

    Even if you could somehow get the object across HTTP (which is possible, but doesn't perform very well) the stateless nature of HTTP(S) will kill you.