glassfish
  1. glassfish
  2. GLASSFISH-9824

DXAR:start():Warning:Received diff Xid for open txnId:switching transactionId

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Incomplete
    • Affects Version/s: v2.1
    • Fix Version/s: V3
    • Component/s: jms
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Linux

    • Issuezilla Id:
      9,824

      Description

      This error appears in the Glassfish log:

      [#|2009-09-29T17:33:31.127+0200|INFO|sun-appserver2.1|javax.enterprise.system.stream.out|_ThreadID=18;_ThreadName=p:
      thread-pool-1; w: 5;|DXAR:start():Warning:Received diff Xid for open
      txnId:switching transactionId:
      DXAR
      Xid=616C636F722C7365727665722C50333730302C010B000000BB566F06616C636F722C7365727665722C5033373030
      DXAR TXid=1776991138030900224
      got Xid=null
      got TXid=1776991138030909184|#]

      Afterwards, this error shows up:
      [#|2009-09-29T17:33:31.134+0200|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=19;_ThreadName=p:
      thread-pool-1; w: 6;java.lang.RuntimeException:
      javax.transaction.xa.XAException;prepare;_RequestID=f0001a51-e07e-4a21-91de-e1de0877be9c;|JTS5031:
      Exception [java.lang.RuntimeException: javax.transaction.xa.XAException] on
      Resource [prepare] operation.|#]

      [#|2009-09-29T17:33:31.136+0200|WARNING|sun-appserver2.1|javax.enterprise.system.core.transaction|_ThreadID=19;_ThreadName=p:
      thread-pool-1; w: 6;_RequestID=f0001a51-e07e-4a21-91de-e1de0877be9c;|JTS5068:
      Unexpected error occurred in rollback
      java.lang.NullPointerException
      at
      com.sun.messaging.jmq.jmsserver.data.handlers.TransactionHandler.doRollback(TransactionHandler.java:1200)
      at
      com.sun.messaging.jmq.jmsserver.data.protocol.ProtocolImpl.rollbackTransaction(ProtocolImpl.java:683)
      at
      com.sun.messaging.jmq.jmsserver.service.imq.IMQDirectService.rollbackTransaction(IMQDirectService.java:1805)
      at com.sun.messaging.jms.ra.DirectXAResource.rollback(DirectXAResource.java:533)
      at com.sun.jts.jta.TransactionState.rollback(TransactionState.java:194)
      at com.sun.jts.jtsxa.OTSResourceImpl.rollback(OTSResourceImpl.java:311)
      at
      com.sun.jts.CosTransactions.RegisteredResources.distributeRollback(RegisteredResources.java:1049)
      at com.sun.jts.CosTransactions.TopCoordinator.rollback(TopCoordinator.java:2297)
      at com.sun.jts.CosTransactions.CoordinatorTerm.commit(CoordinatorTerm.java:410)
      at com.sun.jts.CosTransactions.TerminatorImpl.commit(TerminatorImpl.java:250)
      at com.sun.jts.CosTransactions.CurrentImpl.commit(CurrentImpl.java:623)
      at
      com.sun.jts.jta.TransactionManagerImpl.commit(TransactionManagerImpl.java:309)
      at
      com.sun.enterprise.distributedtx.J2EETransactionManagerImpl.commit(J2EETransactionManagerImpl.java:1003)
      at
      com.sun.enterprise.distributedtx.J2EETransactionManagerOpt.commit(J2EETransactionManagerOpt.java:398)
      at com.sun.ejb.containers.BaseContainer.completeNewTx(BaseContainer.java:3817)
      at com.sun.ejb.containers.BaseContainer.postInvokeTx(BaseContainer.java:3596)
      at
      com.sun.ejb.containers.MessageBeanContainer.afterMessageDeliveryInternal(MessageBeanContainer.java:1226)
      at
      com.sun.ejb.containers.MessageBeanContainer.afterMessageDelivery(MessageBeanContainer.java:1197)
      at
      com.sun.ejb.containers.MessageBeanListenerImpl.afterMessageDelivery(MessageBeanListenerImpl.java:79)
      at
      com.sun.enterprise.connectors.inflow.MessageEndpointInvocationHandler.invoke(MessageEndpointInvocationHandler.java:139)
      at $Proxy73.afterDelivery(Unknown Source)
      at com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:324)
      at com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76)
      at
      com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)

      #]

      This can be reproduced by the attached NB project, were two MDB process messages
      and route them using a given MessageRouterBean.

      1. server.log
        408 kB
        jthoennes

        Activity

        Hide
        Nigel Deakin added a comment -

        These warnings and errors are a consequence of the application using MQ in an
        incorrect manner.

        The problem is the stateless session bean MessageRouterBean. This has a business
        method sendMessage() which sends a message to a queue, using a connection and
        session (provided by the resource adapter) cached in each bean instance.

        The bean method sendMessage() is called from various places, including the
        message-driven bean MessageProcessor01Bean.

        Because sendMessage() is called from multiple MDB instances, a given session
        bean instance will be called by a succession of different threads.

        This violates the JMS restriction that a session object may only be used by a
        single thread at a time.

        Normal session bean behaviour means that the sendMessage() method is only called
        on a given session bean instance by one thread at a time. After this method
        returns, it becomes available for use by a different thread.

        This is, however, invalid as even after the sendMessage() returns, the session
        object remains associated with the calling thread's transaction until the
        transaction is committed at some later time. As a consequence, a subsequent call
        to sendMessage() may find itself trying to use a session object that is still
        being used by some other thread/

        The error is detected by the DirectXAResource object, causes the message
        "DXAR:start():Warning:Received diff Xid for open txnId:switching transactionId"
        and subsequent errors.

        The fix is to change the stateless session bean MessageRouterBean so that the
        business method sendMessage() creates a connection and session, sends the
        message, and immediately closes the connection and session. Note that this
        change will not have any noticeable effect on performance since the connection
        is actually pooled (and in any case the creation of connections and sessions
        when using EMBEDDED mode is very fast).

        Setting resolution as "INVALID"

        Show
        Nigel Deakin added a comment - These warnings and errors are a consequence of the application using MQ in an incorrect manner. The problem is the stateless session bean MessageRouterBean. This has a business method sendMessage() which sends a message to a queue, using a connection and session (provided by the resource adapter) cached in each bean instance. The bean method sendMessage() is called from various places, including the message-driven bean MessageProcessor01Bean. Because sendMessage() is called from multiple MDB instances, a given session bean instance will be called by a succession of different threads. This violates the JMS restriction that a session object may only be used by a single thread at a time. Normal session bean behaviour means that the sendMessage() method is only called on a given session bean instance by one thread at a time. After this method returns, it becomes available for use by a different thread. This is, however, invalid as even after the sendMessage() returns, the session object remains associated with the calling thread's transaction until the transaction is committed at some later time. As a consequence, a subsequent call to sendMessage() may find itself trying to use a session object that is still being used by some other thread/ The error is detected by the DirectXAResource object, causes the message "DXAR:start():Warning:Received diff Xid for open txnId:switching transactionId" and subsequent errors. The fix is to change the stateless session bean MessageRouterBean so that the business method sendMessage() creates a connection and session, sends the message, and immediately closes the connection and session. Note that this change will not have any noticeable effect on performance since the connection is actually pooled (and in any case the creation of connections and sessions when using EMBEDDED mode is very fast). Setting resolution as "INVALID"
        Hide
        jthoennes added a comment -

        Thanks, Nigel, for the detailed explanation.

        But what happens when I close a connection while a XA transaction is going on?
        Will that cause any issues?

        I want be sure to avoid issues by creating and closing the connection locally in
        the session bean: If the method is called from another bean, e.g. Message Driven
        Bean inside a larger transaction, exactly this could happen.

        In addition, is there any way to block stateless session beans until all
        associated transactions are done?

        Thanks, Jörg

        Show
        jthoennes added a comment - Thanks, Nigel, for the detailed explanation. But what happens when I close a connection while a XA transaction is going on? Will that cause any issues? I want be sure to avoid issues by creating and closing the connection locally in the session bean: If the method is called from another bean, e.g. Message Driven Bean inside a larger transaction, exactly this could happen. In addition, is there any way to block stateless session beans until all associated transactions are done? Thanks, Jörg
        Hide
        Nigel Deakin added a comment -

        > But what happens when I close a connection while a XA transaction is going on?
        > Will that cause any issues?

        It should not; closing the connection after you've finished using it is the
        recommended technique.

        The connection object you're working with is actually a wrapper provided by the
        JMS resource adapter which wraps the underlying JMS connection. When you call
        connecton.close() on this wrapper object, the underlying connection isn't really
        closed but remains active. When the transaction is committed the underlying
        connection remains open but is returned to a pool and becomes available for use
        by a subsequent call to createConnection().

        > is there any way to block stateless session beans until all
        > associated transactions are done?

        I don't think so with Glassfish.

        The general advice is: close the session and connection as soon as you no longer
        need them and let the resource adapter look after the lifecycle of the
        underlying resources. The pooling provided by the resource adapter is intended
        to make it unnecessary for the application to cache transactional resources.

        Show
        Nigel Deakin added a comment - > But what happens when I close a connection while a XA transaction is going on? > Will that cause any issues? It should not; closing the connection after you've finished using it is the recommended technique. The connection object you're working with is actually a wrapper provided by the JMS resource adapter which wraps the underlying JMS connection. When you call connecton.close() on this wrapper object, the underlying connection isn't really closed but remains active. When the transaction is committed the underlying connection remains open but is returned to a pool and becomes available for use by a subsequent call to createConnection(). > is there any way to block stateless session beans until all > associated transactions are done? I don't think so with Glassfish. The general advice is: close the session and connection as soon as you no longer need them and let the resource adapter look after the lifecycle of the underlying resources. The pooling provided by the resource adapter is intended to make it unnecessary for the application to cache transactional resources.
        Hide
        houghvw added a comment -

        Hi,

        We are currently on glassfish 2.1 and are experiencing transaction related issues that seems to be related to this issue. The only error we see in the log is "Warning:Received diff Xid for open... "

        Would it be possible to give more detail with regards to the resolution.

        It is not possible for us to upgrade to glassfish v3 at this stage. Is there any patch available for v2 that might include this fix?

        Any help will be much appreciated.

        Regards

        Show
        houghvw added a comment - Hi, We are currently on glassfish 2.1 and are experiencing transaction related issues that seems to be related to this issue. The only error we see in the log is "Warning:Received diff Xid for open... " Would it be possible to give more detail with regards to the resolution. It is not possible for us to upgrade to glassfish v3 at this stage. Is there any patch available for v2 that might include this fix? Any help will be much appreciated. Regards
        Hide
        jthoennes added a comment -

        In reply to comment #10:
        > We are currently on glassfish 2.1 and are experiencing transaction related
        > issues that seems to be related to this issue. The only error we see in the log
        > is "Warning:Received diff Xid for open... "
        >
        > Would it be possible to give more detail with regards to the resolution.

        Comment 7 of Nigel Deakin explains this issue in very much detail. Which point is unclear to you?

        > It is not possible for us to upgrade to glassfish v3 at this stage. Is there any
        > patch available for v2 that might include this fix?

        Unless you have commercial Glassfish support (and even then I guess) you will not get any patch for a GF 2.1.
        Please avoid caching of JMS connection in stateless beans by any means.

        Cheers, Jörg

        Show
        jthoennes added a comment - In reply to comment #10: > We are currently on glassfish 2.1 and are experiencing transaction related > issues that seems to be related to this issue. The only error we see in the log > is "Warning:Received diff Xid for open... " > > Would it be possible to give more detail with regards to the resolution. Comment 7 of Nigel Deakin explains this issue in very much detail. Which point is unclear to you? > It is not possible for us to upgrade to glassfish v3 at this stage. Is there any > patch available for v2 that might include this fix? Unless you have commercial Glassfish support (and even then I guess) you will not get any patch for a GF 2.1. Please avoid caching of JMS connection in stateless beans by any means. Cheers, Jörg

          People

          • Assignee:
            Nigel Deakin
            Reporter:
            jthoennes
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: