JMS not contributing in transactions

Question

Hello,
          I am facing currently a problem with JMS and a stateless sessionbean
          with Trx=RequiresNew. The sessionbean is deployed in its own WLS
          instance. The second WLS has a TopicConnectionFactory setup with User
          Transactions Enabled=false and XAConnection Factory Enabled=false.
          The method causing troubles in the session bean basically looks as
          follows:
          public void process() {
          try {
          doSomething();
          catch (Exception e) {
          publishToJMS("Problem Occurred");
          throw new EKBException("Problem occured",e);
          The problem is, that in case of an exception, the publish is somehow
          rolledback (with a timeout during rollback exception), even that the
          ConnectionFactory does not have the XA/UserTrx attributes set to true.
          Is is contributing to the transaction - I verified this by suspending
          the transaction with the
          weblogic.transaction.TxHelper.getTransactionManager().forceSuspend()/forceResume()
          calls and then everything is working fine.
          This is on WLS6.1SP3 Windows and Solaris.
          Thanks for any help
          Juerg
          

Answer 1

          Tom,
          But when I use a transacted session, the message will not be published in case
          of a rollback.
          This is not what I want. Our JMS system is here for publishing alerts and audits
          and in case of a
          problem I want to publish an alert and then throw an EJBException, so probably
          using
          suspend/resume is the better way. I am really surprised that it does not work
          with User
          Transactions Enabled=false and XAConnection Factory Enabled=false. Is this a bug?
          Thanks
          Juerg
          Tom Barnes <[email protected]> wrote:
          >A transacted session will not work with the XA JMS API - the XA JMS API
          >ignores the transacted flag. Just don't use the "createXAxxxx"
          >variants and you'll be fine in WL. If you care about
          >performance, a transacted session is more costly than a
          >non-transacted non-transactional session so the suspend/resume
          >will do you better.
          >
          >Tom
          >
          >Juerg Staub wrote:
          >> Hi Tom,
          >>
          >> To use a transacted session do I just need to set XAConnection Factory
          >Enabled=true
          >> and call createTopicSession(true,Session.AUTO_ACKNOWLEDGE) or are there
          >any other
          >> steps involved?
          >> I postin from home at the moment, so I will post the config.xml and
          >the code snippet
          >> tomorrow.
          >>
          >> Thanks
          >>
          >> Juerg
          >>
          >> Tom Barnes <[email protected]> wrote:
          >>
          >>>I do not know what is going on. If you like, post your
          >>>config.xml and perhaps the code snippets for looking up the CF
          >>>and creating the connection and I will take a quick look.
          >>>In the mean-time you can
          >>>use suspend/resume, or a transacted session (just remember
          >>>to call session.commit)...
          >>>
          >>>Tom
          >>>
          >>>Juerg Staub wrote:
          >>>
          >>>>Hi Tom,
          >>>>
          >>>>Thanks for your reply.
          >>>>
          >>>>Tom Barnes <[email protected]> wrote:
          >>>>
          >>>>
          >>>>>Are you sure the JNDI name of the connection factory the SSB is using
          >>>>>is the same as the JNDI name for the CF configured with false/false?
          >>>>
          >>>>
          >>>>Yes I am.
          >>>>
          >>>>
          >>>>
          >>>>>Make sure that the publisher is not use a
          >>>>>"transacted" session. (Make sure first parameter
          >>>>>to createTopicSession() is false.)
          >>>>>
          >>>>
          >>>>
          >>>>I use topicConnection.createTopicSession(false,Session.AUTO_ACKNOWLEDGE).
          >>>
          >>>>I see in the console that both WLS have inflight transactions....
          >>>>
          >>>>What else could be wrong?
          >>>>
          >>>>Juerg
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>
          >>>>>Tom
          >>>>>
          >>>>>Juerg Staub wrote:
          >>>>>
          >>>>>
          >>>>>>Hello,
          >>>>>>
          >>>>>>I am facing currently a problem with JMS and a stateless sessionbean
          >>>>>>with Trx=RequiresNew. The sessionbean is deployed in its own WLS
          >>>>>>instance. The second WLS has a TopicConnectionFactory setup with
          >User
          >>>>>>Transactions Enabled=false and XAConnection Factory Enabled=false.
          >>>>>>
          >>>>>>The method causing troubles in the session bean basically looks
          >as
          >>>>>>follows:
          >>>>>>
          >>>>>>
          >>>>>>public void process() {
          >>>>>>
          >>>>>> try {
          >>>>>> doSomething();
          >>>>>> catch (Exception e) {
          >>>>>> publishToJMS("Problem Occurred");
          >>>>>> throw new EKBException("Problem occured",e);
          >>>>>> }
          >>>>>>
          >>>>>>
          >>>>>>The problem is, that in case of an exception, the publish is somehow
          >>>>>>rolledback (with a timeout during rollback exception), even that
          >the
          >>>>>>ConnectionFactory does not have the XA/UserTrx attributes set to
          >true.
          >>>>>>Is is contributing to the transaction - I verified this by suspending
          >>>>>>the transaction with the
          >>>>>>weblogic.transaction.TxHelper.getTransactionManager().forceSuspend()/forceResume()
          >>>>>>calls and then everything is working fine.
          >>>>>>
          >>>>>>This is on WLS6.1SP3 Windows and Solaris.
          >>>>>>
          >>>>>>
          >>>>>>Thanks for any help
          >>>>>>
          >>>>>>Juerg
          >>>>>
          >>
          >