Announcement Announcement Module
Collapse
No announcement yet.
Remoting and transactions. Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Remoting and transactions.

    I have a question about transactions and remoting. Making a remote connection with Spring is peanuts... but how should one deal with transactions and remoting?

  • #2
    Transactions should not normally span the remote invocation--it's a questionable design choice. Normally you invoke a transactional method remotely, and the transaction is contained in the server.

    Spring does not natively support the transaction propagating over the wire if this is what you need. (Unless you're using WebLogic, in which case I believe it does work.) So you need to use EJB remoting rather than POJO-based remoting in this case.

    Comment


    • #3
      Transactions should not normally span the remote invocation--it's a questionable design choice. Normally you invoke a transactional method remotely, and the transaction is contained in the server.
      In some cases a distributed transaction could be handy (I think). How can I else make sure that a message is received and processed on a server?

      Why does remote communication have to be so different from db communication? example:

      RemoteTransaction t = remoteService.createTransaction();
      remoteService.doSomething();
      remoteService.doSomethingElse();
      t.commit();



      Spring does not natively support the transaction propagating over the wire if this is what you need.
      I know.

      The reason I`m asking this is because I`m afraid I have to redesign a system when transactions are needed.


      [edit]
      If I want to order a book and need a SOAP service (or RMI) how can I make sure I only order that book once? How should I design the client and the server?

      Comment


      • #4
        Well, for a single remote method invocation, it should be perfectly sufficient to execute the server-side execution of that invocation within a server-side transaction. The advantage of that approach is that the server doesn't have to rely on the client to complete the transaction: It can reliably complete the transaction before the call returns.

        Of course, if you want to group multiple remote method invocations into one transaction, you do need remote transaction propagation: either through EJB remoting or through running Spring against WebLogic RMI, with the transaction demarcated through WebLogic remote JTA (Spring's JtaTransactionManager is able to work with remote JTA as well).

        Juergen

        Comment


        • #5
          Originally posted by Juergen Hoeller
          Well, for a single remote method invocation, it should be perfectly sufficient to execute the server-side execution of that invocation within a server-side transaction. The advantage of that approach is that the server doesn't have to rely on the client to complete the transaction: It can reliably complete the transaction before the call returns.
          But how does the client know the transaction was succesfull. And how can the client make sure he doesn`t make the same call again? (if the client crashes for example).

          Of course, if you want to group multiple remote method invocations into one transaction, you do need remote transaction propagation: either through EJB remoting or through running Spring against WebLogic RMI, with the transaction demarcated through WebLogic remote JTA (Spring's JtaTransactionManager is able to work with remote JTA as well).
          Aha ok.

          And how do other remoting protocols handle transactions? If I use a webservice for booking vacations.. how can I make sure I don`t book the same vacation twice? How do such processes deal with atomic-actions?

          note to self:
          I have to get a better understanding of JTA and I want to have a better understanding how transactions are implemented.

          Comment


          • #6
            can anybody call other than BEA RMI implementation or framework that supports transaction propagation? can sun RMI/IIOP propagate context with a help of a framework?

            we are building a solution based on free -) software....

            can we user jtom, geronimo(with its good recovery log) as remote TM?

            Comment


            • #7
              Hi,

              I'm having a problem using transactions in POJO-based remoting. I understand from the previous posts in this thread that this is only possible in Weblogic, which is the container I use.

              Without going into too many details, I use the following Spring configuration:

              <bean id="my-bean" class="org.springframework.transaction.interceptor .TransactionProxyFactoryBean" lazy-init="true">
              <property name="transactionManager" ref="transaction-manager"/>
              .....
              .....
              </bean>

              <bean id="transaction-manager" class="org.springframework.transaction.jta.WebLogi cJtaTransactionManager" lazy-init="true">
              <property name="jndiTemplate" ref="my-jndi-template"/>
              </bean>

              <bean id="my-jndi-template" class="org.springframework.jndi.JndiTemplate">
              <property name="environment">
              <props>
              <prop key="java.naming.provider.url">${foreignJndiProvid erUrl}</prop>
              <prop key="java.naming.factory.initial">weblogic.jndi.WL InitialContextFactory</prop>
              </props>
              </property>
              </bean>

              When I call a transacted method on my-bean, I get the following error on the client-side:

              javax.transaction.SystemException: You may enlist a resource only on a server

              How can I solve this issue?

              Thanks in advance!

              Regards,
              Henrik Oddershede

              Comment


              • #8
                Originally posted by Juergen Hoeller View Post
                Well, for a single remote method invocation, it should be perfectly sufficient to execute the server-side execution of that invocation within a server-side transaction. The advantage of that approach is that the server doesn't have to rely on the client to complete the transaction: It can reliably complete the transaction before the call returns.

                Of course, if you want to group multiple remote method invocations into one transaction, you do need remote transaction propagation: either through EJB remoting or through running Spring against WebLogic RMI, with the transaction demarcated through WebLogic remote JTA (Spring's JtaTransactionManager is able to work with remote JTA as well).

                Juergen
                Juergen, there is any example of transaction propagation through Spring against WebLogic RMI? Thatīs exactly what I need.

                Thanks,

                Comment

                Working...
                X