Causing onMessage in MDB to rollback

Question

          Is it possible for a pub/sub MDB to "unconsume" a message? I have successfully
          rolled back a message consumed by a point-to-point MDB, but not one consumed by
          a pub/sub MDB.
          I am using WLS 7.0 and MQ 5.3. My deployment descriptor specifies container management
          and durable subscriber
          The logic for the p2P and pub/sub MDBs is similar. The onMessage rejects every
          other message (based on a static member counter), either via context.setRollbackOnly()
          or throwing an EJBException (I've tried implementing both). For pub/sub, I have
          2 MDBs, the second MDB accepts all messages. In p2p, when a message is rejected,
          it is re-consumed by the next bean that the container instantiates. In pub/sub
          a message that is accepted by bean 1 is also read by bean 2. A message that is
          rejected by bean 1 is read by bean 2, but bean 1 does not retry, indicating that
          the message was not returned to the topic for bean 1.
          Am I missing something, or is it not possible to return a message to a topic once
          a subscribing MDB has retrieved it?
          TIA,
          Ed
          

Answer 1

One thing is that you are not running transactionally. In order to
          get transactions, "onMessage()" for each MDB needs to be set to
          "Required":
          <assembly-descriptor>
          <container-transaction>
          <method>
          <ejb-name>exampleMessageDrivenA</ejb-name>
          <method-name>onMessage()</method-name>
          </method>
          <trans-attribute>Required</trans-attribute>
          </container-transaction>
          </assembly-descriptor>
          Ed Trembicki-Guy wrote:
          > Thanks Tom. Here are the descriptor files:
          >
          > ejb-jar.xml:
          >
          > <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans
          > 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
          >
          > <!-- Generated XML! -->
          >
          > <ejb-jar>
          > <enterprise-beans>
          > <message-driven>
          > <ejb-name>PTPMsgBean</ejb-name>
          > <ejb-class>com.roxy.ejb.WLMsgBean</ejb-class>
          > <transaction-type>Container</transaction-type>
          > <message-driven-destination>
          > <destination-type>javax.jms.Queue</destination-type>
          > </message-driven-destination>
          >
          > </message-driven>
          > <message-driven>
          > <ejb-name>PubSubMsgBean</ejb-name>
          > <ejb-class>com.roxy.ejb.WLPubSubMsgBean</ejb-class>
          > <transaction-type>Container</transaction-type>
          > <message-driven-destination>
          > <destination-type>javax.jms.Topic</destination-type>
          > <subscription-durability>Durable</subscription-durability>
          > </message-driven-destination>
          >
          > </message-driven>
          > <message-driven>
          > <ejb-name>PubSubMsgBean2</ejb-name>
          > <ejb-class>com.roxy.ejb.WLPubSubMsgBean2</ejb-class>
          > <transaction-type>Container</transaction-type>
          > <message-driven-destination>
          > <destination-type>javax.jms.Topic</destination-type>
          > <subscription-durability>Durable</subscription-durability>
          > </message-driven-destination>
          >
          > </message-driven>
          > </enterprise-beans>
          >
          > </ejb-jar>
          >
          > <?xml version="1.0" encoding="UTF-8"?>
          > <!DOCTYPE weblogic-ejb-jar PUBLIC '-//BEA Systems, Inc.//DTD WebLogic 7.0.0 EJB//EN'
          > 'http://www.bea.com/servers/wls700/dtd/weblogic-ejb-jar.dtd'>
          >
          > weblogic-ejb-jar.xml:
          >
          > <!-- Generated XML! -->
          >
          > <weblogic-ejb-jar>
          > <weblogic-enterprise-bean>
          > <ejb-name>PTPMsgBean</ejb-name>
          > <message-driven-descriptor>
          > <pool>
          > <max-beans-in-free-pool>1</max-beans-in-free-pool>
          > <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
          > </pool>
          >
          > <destination-jndi-name>mqQ</destination-jndi-name>
          > <connection-factory-jndi-name>mqQCF</connection-factory-jndi-name>
          > </message-driven-descriptor>
          >
          > </weblogic-enterprise-bean>
          > <weblogic-enterprise-bean>
          > <ejb-name>PubSubMsgBean</ejb-name>
          > <message-driven-descriptor>
          > <pool>
          > <max-beans-in-free-pool>1</max-beans-in-free-pool>
          > <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
          > </pool>
          >
          > <destination-jndi-name>mqT</destination-jndi-name>
          > <connection-factory-jndi-name>mqTCF</connection-factory-jndi-name>
          > </message-driven-descriptor>
          >
          > </weblogic-enterprise-bean>
          > <weblogic-enterprise-bean>
          > <ejb-name>PubSubMsgBean2</ejb-name>
          > <message-driven-descriptor>
          > <pool>
          > <max-beans-in-free-pool>1</max-beans-in-free-pool>
          > <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
          > </pool>
          >
          > <destination-jndi-name>mqT</destination-jndi-name>
          > <connection-factory-jndi-name>mqTCF</connection-factory-jndi-name>
          > </message-driven-descriptor>
          >
          > </weblogic-enterprise-bean>
          > </weblogic-ejb-jar>
          >
          > Tom Barnes <[email protected]> wrote:
          >
          >>Hi Ed,
          >>
          >>It should be possible, but with one caveat: If the
          >>subscriber is non-durable, then a JMS vendor has the option
          >>of simply "forgetting" or "dropping" a message on
          >>a rollback. WL JMS does not do this (we think
          >>this behavior makes nondurable less useful), but
          >>IBM JMS may. Actually, the JMS spec specifically gives
          >>vendors the option of arbitrarily dropping
          >>pub/sub messages to nondurable subscribers for
          >>ANY reason, and a few vendors take advantage of this.
          >>
          >>Anyhow, if you post your descriptor xml files I'll
          >>take a quick look.
          >>
          >>You may want to try a test with WL JMS as the topic
          >>provider to see if that narrows the problem down
          >>to something in MQ or possibly something in the WL
          >>container "foreign vendor" integration code.
          >>
          >>Tom
          >>
          >>Ed Trembicki-Guy wrote:
          >>
          >>
          >>>Is it possible for a pub/sub MDB to "unconsume" a message? I have
          >>
          >>successfully
          >>
          >>>rolled back a message consumed by a point-to-point MDB, but not one
          >>
          >>consumed by
          >>
          >>>a pub/sub MDB.
          >>>
          >>>I am using WLS 7.0 and MQ 5.3. My deployment descriptor specifies
          >>
          >>container management
          >>
          >>>and durable subscriber
          >>>
          >>>The logic for the p2P and pub/sub MDBs is similar. The onMessage rejects
          >>
          >>every
          >>
          >>>other message (based on a static member counter), either via context.setRollbackOnly()
          >>>or throwing an EJBException (I've tried implementing both). For pub/sub,
          >>
          >>I have
          >>
          >>>2 MDBs, the second MDB accepts all messages. In p2p, when a message
          >>
          >>is rejected,
          >>
          >>>it is re-consumed by the next bean that the container instantiates.
          >>
          >>In pub/sub
          >>
          >>>a message that is accepted by bean 1 is also read by bean 2. A message
          >>
          >>that is
          >>
          >>>rejected by bean 1 is read by bean 2, but bean 1 does not retry, indicating
          >>
          >>that
          >>
          >>>the message was not returned to the topic for bean 1.
          >>>
          >>>Am I missing something, or is it not possible to return a message to
          >>
          >>a topic once
          >>
          >>>a subscribing MDB has retrieved it?
          >>>
          >>>TIA,
          >>>Ed
          >>>
          >>
          >