Transaction in mdb

hello
i write a message driven bean,that monitor the weblogic message queue,when a "Order"
object is witten to the queue,the mdb get it and write it to a entity bean "Orderinfo".all
of above logic is within the "onMessage" method of the mdb.
i want to encapsulate the flow in a transaction,see my code snippet of the onMessage
method:
ObjectMessage objMsg = (ObjectMessage) msg;
OrderVO orderVO = (OrderVO) objMsg.getObject();
System.out.println(orderVO.booklist);
OrderinfoHome orderinfoHome = (OrderinfoHome) ctx.lookup(
"java:/comp/env/orderinfo");
Orderinfo orderinfo = orderinfoHome.create(orderVO.orderID);
orderinfo.setAddress(orderVO.address);
orderinfo.setCustname(orderVO.custName);
orderinfo.setEmail(orderVO.email);
orderinfo.setBooklist(orderVO.booklist);
orderinfo.setPrice(new BigDecimal(orderVO.price));
and deploy descriptor snippet(ejb-jar.xml):
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>orderMDB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
i think during this transaction,there are two action:geting the object from the
queue and saving it to entity bean.in order to test the transaction,i modify the
jndi name of entity bean in the code to a WRONG one.redeploy my program,and send
a message to the queue,the mdb is activated,then the exception is thrown because
of the wrong jndi name.after that,i check the message queue,find that it is empty.why?i
think if the second action of the transaction is fail,the transaction should roll
back,the message should be send BACK to the queue.
i also ty to use the "javax.transaction.UserTransaction" in the onMessage method,but
the follwing exception is thrown:
javax.transaction.NotSupportedException: Another transaction is associated with
this thread.................................
who can help me,if any wrong with me,and how to use the transaction with the message
driven bean?
thank you.

Hi,
A failure to lookup a jndi name will throw NamingException and this will not rollback
the tx. To rollback the tx, you need to explicity set the tx context status to
rollbackonly or throw a system exception ( which will discard that MDB instance).
Application exceptions do not rollback the tx.
In your scenario, the tx started on invoking onMessage routine and infects the
Entity beans business method. You can either throw a system exception in either
the onMessage routine or the entity beans business method or explicity set the
tx status to rollbackonly to rollback the tx.
ram
"zhebincong" <[email protected]> wrote:
>
hello
i write a message driven bean,that monitor the weblogic message queue,when
a "Order"
object is witten to the queue,the mdb get it and write it to a entity
bean "Orderinfo".all
of above logic is within the "onMessage" method of the mdb.
i want to encapsulate the flow in a transaction,see my code snippet of
the onMessage
method:
ObjectMessage objMsg = (ObjectMessage) msg;
OrderVO orderVO = (OrderVO) objMsg.getObject();
System.out.println(orderVO.booklist);
OrderinfoHome orderinfoHome = (OrderinfoHome) ctx.lookup(
"java:/comp/env/orderinfo");
Orderinfo orderinfo = orderinfoHome.create(orderVO.orderID);
orderinfo.setAddress(orderVO.address);
orderinfo.setCustname(orderVO.custName);
orderinfo.setEmail(orderVO.email);
orderinfo.setBooklist(orderVO.booklist);
orderinfo.setPrice(new BigDecimal(orderVO.price));
and deploy descriptor snippet(ejb-jar.xml):
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>orderMDB</ejb-name>
<method-name>*</method-name>
</method>
<trans-attribute>Required</trans-attribute>
</container-transaction>
</assembly-descriptor>
i think during this transaction,there are two action:geting the object
from the
queue and saving it to entity bean.in order to test the transaction,i
modify the
jndi name of entity bean in the code to a WRONG one.redeploy my program,and
send
a message to the queue,the mdb is activated,then the exception is thrown
because
of the wrong jndi name.after that,i check the message queue,find that
it is empty.why?i
think if the second action of the transaction is fail,the transaction
should roll
back,the message should be send BACK to the queue.
i also ty to use the "javax.transaction.UserTransaction" in the onMessage
method,but
the follwing exception is thrown:
javax.transaction.NotSupportedException: Another transaction is associated
with
this thread.................................
who can help me,if any wrong with me,and how to use the transaction with
the message
driven bean?
thank you.

Similar Messages

  • Problem about transaction of  mdb

    I've made a MDB,it works fine in WLS7.0, but when I upgraded the server from WLS7.0 to WLS8.1, I found this error:
              java.sql.SQLException: Cannot call Connection.rollback in distributed transaction. Transaction Manager will commit the resource manager when the distributed transaction is committed.
              at weblogic.jdbc.wrapper.JTSConnection.rollback()V(JTSConnection.java:570)
              at com.aspire.syn.delivery.ReceiverMDBean.onMessage(Ljavax.jms.Message;)V(ReceiverMDBean.java:320)
              at weblogic.ejb20.internal.MDListener.execute(Lweblogic.kernel.ExecuteThread;)V(MDListener.java:370)
              at weblogic.ejb20.internal.MDListener.onMessage(Ljavax.jms.Message;)V(MDListener.java:262)
              at weblogic.jms.client.JMSSession.onMessage(Ljavax.jms.MessageListener;Lweblogic.jms.common.MessageImpl;)V(JMSSession.java:2678)
              at weblogic.jms.client.JMSSession.execute(Lweblogic.kernel.ExecuteThread;)V(JMSSession.java:2598)
              at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(ExecuteThread.java:219)
              at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:178)
              at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source)
              connection.close() exception:Cannot call Connection.rollback in distributed transaction. Transaction Manager will commit the resource manager when the distributed transaction is committed.
              JMS Connection Factories is "XA Connection Factory Enabled" , and I used a oracle jdbc datasource
              The mdb code as below:
              public void onMessage(Message msg){       
              java.sql.Connection conn = null;
              ...get the connection
              try{
              conn.setAutoCommit(false);
              ...business flow
              conn.commit();
              conn.close();
              } catch(JMSException jmse){
              try{
              conn.rollback();
              } catch(SQLException ee){}
              messageDrivenContext.setRollbackOnly();
              } catch(Exception e){
              try{
              conn.rollback();
              } catch(SQLException ee){}
              e.printStackTrace();
              messageDrivenContext.setRollbackOnly();
              I have specified the attributes in ejb-jar.xml as per weblogic documentation as below:
              <ejb-jar>
              <enterprise-beans>
              <message-driven>
              <description>Message driven Bean to receive Siebel messages</description>
              <ejb-name>ReceiverMDBean</ejb-name>
              <ejb-class>cignex.jms.ReceiverMDBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              </message-driven-destination>
              </message-driven>
              </enterprise-beans>
              <assembly-descriptor>
              <container-transaction>
              <method>
              <ejb-name>ReceiverMDBean</ejb-name>
              <method-name>*</method-name>
              </method>
              <trans-attribute>Required</trans-attribute>
              </container-transaction>
              </assembly-descriptor>
              </ejb-jar>
              Can someone help me with this.
              Thanks!

    Thanks for ur help!
              WLS 8.1
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="JDBCDataSource" Name="JDBCDataSource"
              PoolName="JDBCConnectionPool" Targets="myserver"/>
              WLS 7.0
              <JDBCDataSource JNDIName="JDBCDataSource" Name="JDBCDataSource" PoolName="JDBCConnectionPool"/>
              Because JDBCDataSource is the default datasource when you create a new datasource in WLS7.0, JDBCTXDataSource is the default datasource in WLS8.1.
              After I changed the config.xml, it's ok!
              > Can u please post the DB Connection Pool & DataSource
              > part of config.xml from both (7 & 8.1) your
              > environments ?
              >
              >
              > Cheers!
              > Dips

  • Problem starting transaction for MDB

              Hello All,
              I have a MDB configured as Container managed transaction.
              Sometimes I rollback a message sent to a Queue.
              The problem is that sometimes the WEBLOGIC log show the follow error and do not
              start a JMS service.
              Anyone had this problem before?
              Thanks.
              <Mar 3, 2004 4:51:13 PM GMT-03:00> <Error> <JTA> <BEA-110424> <An unexpected exception
              was caught during begin: java.lang.NullPointerException
              at java.security.SecureRandom.setSeed(SecureRandom.java:369)
              at weblogic.transaction.internal.XidImpl.seedRandomGenerator(XidImpl.java:378)
              at weblogic.transaction.internal.XidImpl.create(XidImpl.java:266)
              at weblogic.transaction.internal.TransactionManagerImpl.getNewXID(TransactionManagerImpl.java:1719)
              at weblogic.transaction.internal.TransactionManagerImpl.internalBegin(TransactionManagerImpl.java:249)
              at weblogic.transaction.internal.ServerTransactionManagerImpl.internalBegin(ServerTransactionManagerImpl.java:303)
              at weblogic.transaction.internal.ServerTransactionManagerImpl.begin(ServerTransactionManagerImpl.java:259)
              at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:253)
              at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
              at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              >
              <Mar 3, 2004 4:51:13 PM GMT-03:00> <Error> <JMS> <BEA-040368> <The following exception
              has occurred:
              java.lang.RuntimeException: [EJB:010166]Error occurred while starting transaction:
              javax.transaction.SystemException: java.lang.NullPointerException.
              at weblogic.ejb20.internal.MDListener.onMessage(MDListener.java:277)
              at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:2596)
              at weblogic.jms.client.JMSSession.execute(JMSSession.java:2516)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              >
              

    Thanks for ur help!
              WLS 8.1
              <JDBCTxDataSource EnableTwoPhaseCommit="true"
              JNDIName="JDBCDataSource" Name="JDBCDataSource"
              PoolName="JDBCConnectionPool" Targets="myserver"/>
              WLS 7.0
              <JDBCDataSource JNDIName="JDBCDataSource" Name="JDBCDataSource" PoolName="JDBCConnectionPool"/>
              Because JDBCDataSource is the default datasource when you create a new datasource in WLS7.0, JDBCTXDataSource is the default datasource in WLS8.1.
              After I changed the config.xml, it's ok!
              > Can u please post the DB Connection Pool & DataSource
              > part of config.xml from both (7 & 8.1) your
              > environments ?
              >
              >
              > Cheers!
              > Dips

  • Sharing transactions with MDB and JDO

    Hi all.
    I'm in immediate need of an answer to my question. I currently have a Message Driven Bean that at most serves 2 functions. First it updates a FastObjects datastore using JDO and second it will send a JMS message to another queue. I want these functions to operate as a transaction. For example, if I update the datastore successfully but sending the JMS message fails, I would need to rollback the datastore update. Can anyone please shed some light on this problem. It would be greatly appreciated.
    Thank You.

    Hey There.
    You should be able to accomplish this by setting the transaction isolation level on your bean.
    Set the method that performs these two operations(save to db and message) to "requires new". If anything fails in the body of the method, rollback the transaction, and throw an exception.
    Hope this helps.
    Vic

  • Container managed transactions in 9.0.3 (plus AQ JMS/MDB)

    Something for "real programmers", similar to MDB Transaction Exception on OC4J 9.0.4 (MDB Transaction Exception on OC4J 9.0.4) but little bit different. Maybe author of the mentioned thread can find some answers here also.
    We have an MDB accessing AQ in database (this works either with 9i and 8i). MDB receives the message (actually TextMessage), retrieves the content/properties and calls some EJBs making database operations. When we used just the same DataSource for JMS resource provider and SQL operations, everything worked OK. But we need to move one step further - making calls to several databases, some 8i, some might 9i. We were able to start CMT for one DataSource, i. e. configuring OrionCMTDataSource over JDBC ORACLE driver (if you use different DataSource class, message remains stucked in queue and eventually expires. If you don't specify container managed transactions for MDB in ejb-jar.xml, it works with any DataSource class - but message is lost every time exception occurs - not very pleasant situation).
    We are trying to configure DataSources so they provide transactional support while using commit coordinator. There are some documents describing this - in 9iAS Data Sources and JTA, Orion Data Sources and possibly JTA description in 9i database documentation. Both ORACLE documents are very similar. Generally, these are main steps:
    1) configure each data source so they provides CMT support (wrap native driver/data source by OrionCMTDataSource class)
    2) create datasource commit-coordinator database, also using CMT(?)
    3) create user in commit-coordinator database and same in each other database with connect, resource, create session + force any transaction priviledge (since it would commit other users transactions)
    4) create database links from commit-coordinator database to each databases (but... see questions below)
    5) configure commit coordinator so it uses proper data source
    6) add each DB link as a property to data sources
    7) configure data source for JMS
    8) connect JMS resource provider with JMS data source
    9) Start container, send message, etc.
    So far the only result we've got is a trace file in database user dumps and generic "javax.transaction.SystemExeption: Could not commit: error code 29540". User dump occurs in a "remote" database, not the one where commit coordinator resides. If I drop database links, result is the same, so it seems like problem with data source itself. In a dump there is piece of text like this: "FATAL ERROR IN TWO-TASK SERVER: error = 12571" and "ksedmp: internal or fatal error
    Current SQL statement for this session:
    begin dbms_aqin.aq$_dequeue_in( :1, :2, :3, :4, :5, :6, :7, :8, :9, :10, :11, :12, :13, :14, :15, :16, :17, :18, :19, :20, :21, :22, :23, :24, :25, :26, :27, :28, :29); end; ". I think AQ call is just a coincidence since it is the first one involved in transactions. Down there in HEX part of a dump there is a message about protocol or network error ("probably ORA-28546")
    Here is an example of data source configuration we are using:
    <!-- Passport CMT DataSource -->
    <data-source
    name="PassportDS"
    class="com.evermind.sql.OrionCMTDataSource"
    location="jdbc/PassportDS"
    connection-driver="oracle.jdbc.driver.OracleDriver"
    username="int"
    password="int"
    url="jdbc:oracle:thin:@ws18885:1521:ICON"
    inactivity-timeout="30">
    <property name="dblink" value="ICON.WS18885.APPG.COM"/>
    There are some questions pending. Obvious one is if CMT is working or not at all and we should find some different solution (Bean managed transactions or use XA, hmmm). Other one might be that database link has to be "fully-qualified". I'm not sure what it means: using username and password? Using database name along with domain (if any)? So far it seems links are not used anyway.
    We've tried several databases, like 9.2.0.1 and 9.0.3 versions. Result is the same.
    We've tried to use XA data source of ORACLE (oracle.jdbc.xa.client.OracleXADataSource) and OrionCMT data source bound by xa-source-location to it but container gets stucked upon restart with "Investingating resource 'XADataSource PassportXADS' for recovery..." and similar messages for an hour.
    There is an OracleJTADataSource mentioned in several documents, but I cannot find any in jdbc classes - was it deprecated?
    Lies the problem in JMS itself? So far we've been able to use AQ in 8i and 9i and succesfully commit every transaction - provided transaction was local.
    Since XA itself is working I guess problem might be with configuration.
    I will appreciate any opinion on CMT... also, if you have any questions, please ask.
    Myrra

    Hi Per,
    I don't have an answer for you -- sorry {:-( -- only a suggestion (which
    you may have already tried, anyway :-). Have you tried running OC4J
    in "debug" mode? The following web-page gives details on how to do that:
    http://kb.atlassian.com/content/atlassian/howto/orionproperties.jsp
    Also, if you aren't already aware of them, the following web-sites
    may also be helpful (not in any particular order):
    http://www.orionserver.com
    http://www.orionsupport.com
    http://www.elephantwalker.com
    Good Luck,
    Avi.

  • Message Driven Bean and transaction handling

    We are using container managed transactions with MDB's running on OC4J version 10.1.2. We have two database serveres, both running Oracle 10g.
    The MDB consume messages from the AQ-database through JMS (connected to a JDBC datasource registered as "jdbc/OracleAQDS").
    The MDB onMessage() code update the second database, using a JDBC datasource registered as "jdbc/OracleDBDS".
    We need atomic behaviour - if the MDB enforce a roll-back we want the updates aginst the second database to be rolled-back as well.
    (1) Should we use XA-datasources since AQ and DB runs on two different servers or do the OC4J container "magically" provide two-phase-commit for us?
    (2) If the MDB does a roll-back we would like to add an error record to a database table. Can we configure a third datasource and prevent if from beeing part of the container managed MDB roll-back?
    (3) When the MDB force a roll-back, is there some way for us to override the retry-delay in our Java code? If we catch certain errors during processing in onMessage we know that it is not necessary to retry for at least one hour (while less severe errors should be retried in just seconds).

    {color:#008000}Hi Friends,
    Thought of updating the answers for my questions in case somebody else would find it helpful.
    {color}
    {color:#999999}{color:#00ccff}I'm trying to make message driven bean and use the OnListener method.
    But since I'm doing this for the first time I have very limited knowledge.
    The following are my doubts :
    1. Should I have a main function while using the MDB?{color}
    {color:#008000} There is no need for any main function.{color}
    {color:#00ccff}2. Is it mandatory to have JNDI setup done?
    {color} {color}{color:#008000} There is no need for any JNDI setup done. But you need to configure the details on the
    Websphere by creating valid entries inside Resources namely -
    Queue Connection Factory, Queues and Listener Ports under the server.
    Thanks,
    Arun Prithviraj{color}

  • MDB and XA

     

              Thanks for your help Tom,
              It turns out I didn't have a transaction. Took a while to track it down...thanks
              again...
              Tom Barnes <[email protected]> wrote:
              >Hi Allen,
              >
              >Your JDBC configuration looks correct, but I may be wrong. I suggest
              >posting to the JDBC newsgroup for confirmation. It might be
              >helpful if you post your MDB xml descriptors.
              >
              >Is your JDBC call embedded directly in the MDB, or does the MDB invoke
              >it through another EJB or RMI class?
              >
              >It seems like there may be no transaction even though you set required?
              >To see if the current thread is infected with a live transaction, you
              >can insert some trace code:
              >Call weblogic.transaction.TxHelper.getTransaction() to get the current
              >transaction, then call weblogic.transaction.Transaction.getStatusAsString()
              >to
              >see its status.
              >
              >
              >Tom
              >
              >Allen Miller wrote:
              >
              >> I have a transaction 'required' mdb that essentially instantiates a
              >class that
              >> does database updates. I get the exception below. It appears the database
              >operations
              >> are not running as part of the mdb's transaction.
              >>
              >> I've configured the weblogic supplied oracle xa driver and tx datasourse
              >per the
              >> doc (as I understand it). The code snippet retrieving the datasource
              >and the config.xml
              >> definitions follow the exception message below.
              >>
              >> weblogic 6.1 on win2000
              >>
              >> any ideas???
              >>
              >> SQL operations are not allowed with no global transaction by default
              >for XA drivers.
              >> If the XA driver supports performing SQL operations with no global
              >transaction,
              >> explicitly allow it by setting "SupportsLocalTransaction" JDBC connection
              >pool
              >> property to true. In this case, also remember to complete the local
              >transaction
              >> before using the connection again for global transaction, else a XAER_OUTSIDE
              >> XAException may result. To complete a local transaction, you can either
              >set auto
              >> commit to true or call Connection.commit().
              >>
              >> Context ctx = new InitialContext();
              >> javax.sql.DataSource ds = (javax.sql.DataSource)
              >ctx.lookup ("jdbc/" + "ListenPointReporterConnectionsDs");
              >> return ds.getConnection();
              >>
              >> <JDBCConnectionPool CapacityIncrement="1"
              >> DriverName="weblogic.jdbc.oci.xa.XADataSource"
              >> InitialCapacity="2" LoginDelaySeconds="1" MaxCapacity="15"
              >> Name="PlatformListenPointReporterConnections"
              >> Properties="user=allen;password=allen;dataSourceName=PlatformListenPointReporterConnections;server=alcatraz;serverName=alcatraz"
              >> ShrinkPeriodMinutes="30" ShrinkingEnabled="true"
              >> Targets="listenpointServer" TestConnectionsOnRelease="true"
              >> TestConnectionsOnReserve="true" TestTableName="LP_USER_V"/>
              >>
              >> <JDBCTxDataSource EnableTwoPhaseCommit="true"
              >> JNDIName="jdbc/ListenPointReporterConnectionsDs"
              >> Name="ListenPointReporterConnectionsDs"
              >> PoolName="PlatformListenPointReporterConnections" Targets="listenpointServer"/>
              >
              

  • How to configure MDB as Durable Subscriber

              I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
              I tried using the Edit EJB Descriptor link in the console. I then drilled down
              to Message Driven Destination. For Subscription Durability, I selected Durable.
              I clicked Apply. I also went back to the jar and pressed the Persist button to
              "Persist changes made to the Descriptor(s)".
              I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
              the server. Still no.
              What am I missing? The only info I can find in the documentation about setting
              up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
              Using WL v6 SP5, not clustered.
              Any help would be appreciated.
              Jim
              

    Hi James,
              I'm unfamiliar with the console ejb xml editor. I suggest
              posting to the ejb newsgbroup, which is more familiar
              with these things. Meanwhile, the attached notes
              and the following example may help if your willing
              to hand-edit the xml.
              Tom, BEA
              <ejb-jar>
              <enterprise-beans>
              <message-driven>
              <ejb-name>exampleMessageDrivenA</ejb-name>
              <ejb-class>MessageBean</ejb-class>
              <transaction-type>Container</transaction-type>
              <message-driven-destination>
              <destination-type>javax.jms.Queue</destination-type>
              <!--
              <destination-type>javax.jms.Topic</destination-type>
              <subscription-durability>Durable</subscription-durability>
              -->
              </message-driven-destination>
              </message-driven>
              </enterprise-beans>
              <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>
              </ejb-jar>
              <!-- Sample MessageDriven bean Weblogic deployment descriptor -->
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleMessageDrivenA</ejb-name>
              <message-driven-descriptor>
              <pool>
              <max-beans-in-free-pool>5</max-beans-in-free-pool>
              <initial-beans-in-free-pool>5</initial-beans-in-free-pool>
              </pool>
              <!--
              <destination-jndi-name>quotestopic</destination-jndi-name>
              -->
              <destination-jndi-name>MDBQ</destination-jndi-name>
              <!--
              <provider-url>t3://localhost:10001</provider-url>
              <connection-factory-jndi-name>cf3</connection-factory-jndi-name>
              <jms-client-id>cid444</jms-client-id>
              -->
              </message-driven-descriptor>
              <jndi-name>someid</jndi-name>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              James Goodwin wrote:
              > I can't seem to find any documentation on how to set up an MDB as a Durable Subscriber.
              > I tried using the Edit EJB Descriptor link in the console. I then drilled down
              > to Message Driven Destination. For Subscription Durability, I selected Durable.
              > I clicked Apply. I also went back to the jar and pressed the Persist button to
              > "Persist changes made to the Descriptor(s)".
              >
              > I check the Topic to see if there were any Durable Subscribers listed. No. I bounced
              > the server. Still no.
              >
              > What am I missing? The only info I can find in the documentation about setting
              > up Durable Subscriptions is via the JMS API (http://e-docs.bea.com/wls/docs61/jms/implement.html#1097632)
              >
              > Using WL v6 SP5, not clustered.
              >
              > Any help would be appreciated.
              >
              > Jim
              A durable topic subscriber MDB uses its name to generate its client-id.
              Since JMS enforces uniqueness on this client-id, this means that if a durable
              subscriber MDB is deployed to multiple servers only one server will be able
              to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The durable subscription is uniquely identified within a cluster by a
              combination of "connection-id" and "subscription-id". Only one active
              connection may use a particular "connection-id" within a WebLogic cluster.
              The connection id comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              Work-around:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              

  • Transaction Timeout behaviour

    I am doing some testing to reproduce a production scenario where we ended up with messages stuck in JMS queue in receive state ( weblogic 10.3.3)...
    The flow is as below:
    JMS Queue --> Transactional MDB with resource reference
    The MDB makes a callout to http service . No read time out configured for the http invocation
    Transaction Timeout : 10 minutes for the MDB
    I put a Thread.sleep in the target http service for 11 minutes
    Tested by placing a message in the queue. MDB picked the message and made http call. Message substate was receive-transaction. Queue had redelivery delay of 55 seconds and redelivery limit of -1.
    I would like to know what is the designed behaviour in this scenario when transaction timeout occurs at 10 minutes. ?
    The behaviour I observed,
    From JTA Monitoring ,At 602nd second, transaction was marked for rolled back, though the MDB code was executing [ I think this is the correct behaviuor]
    Message substate was receieve-transaction till end of 660th second, when it got redelivered. Redelivery count increased by 1. I was expecting message substate to change to delayed, but it didn't,. New substate after 660th second was also receive transaction. In JTA monitoring I could also see a new transaction spawning up.
    The whole purpose of my experiment was to reproduce the scenrio we are observing messages in 'receive' state when http service goes out. Any suggestion how i can get this, all I could get is receive transaction.
    Thanks In Advance.

    So if the delay is set to 11 minutes, but the message is trapped in a receive transaction that times out after 10 minutes, there will only be a 1 minute redelivery delay... Thanks Tom. This is eaxctly the behaviour I am observing. And if redelivery delay is less than transaction timeout period, message is redelivered instantaneously when the transaction timeout occurs.
    It seems you're looking into the final details of the "redelivery delay" feature's behavior? I am looking at how to trap the message in receive state. We are seeing messages stuck in receive state in production when http service goes out and it occurs randomly. My guess is since we have not configured http read time out, the socket timeout occurs at a time beyond transaction timeout and some of the complex underlying behaviours at transaction timeout event is the reason for this [ could even be a bug when dealing with this abnormal condition].
    A solution for this is to set out the http read time out less than transaction timeout. We have done this in prod now and since we cant reproduce the issue , we dont know whether it fixes the problem. We are now waiting to see if the issue reoccurs . The customer doesn't like this and wants us to reproduce the issue for confirmation.
    I am looking at the message substate transitions. I know for transactional weblogic MDB's and non UOO messages, the state transition will be :
    Visible --> receive --> receive transaction --> transaction committed or rolled back
    In this transition , it is possible for messge in receive transaction to revert back to receive status ?
    P.S. we have spent huge amount of time and effort with Oracle support with no real solutions. They want us to tell them the method to reproduce the issue.

  • Deploy MDBs in Different WL Instances Subscribed to Same Topic

              Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different Weblogic
              server. All need to subscribe to the same Topic. How is this done? Specifically,
              how is the Topic configured and how are the MBDs deployed?
              Thanks,
              Jim Goodwin
              

    For your reading enjoyment, I'm posting some of my
              internal notes on durable subscriber MDB's. This consolidates
              newsgroup information in one place.
              Jim Goodwin wrote:
              > "Jim Goodwin" <[email protected]> wrote:
              >
              >>Let's say I have MDBs X, Y, and Z, each needing to be deployed to a different
              >>Weblogic
              >>server. All need to subscribe to the same Topic. How is this done? Specifically,
              >>how is the Topic configured and how are the MBDs deployed?
              >>
              >>Thanks,
              >>
              >>Jim Goodwin
              >
              >
              > Bah! Nevermind. I found the information I was looking for in other threads.
              A durable topic subscriber MDB uses its name to generate its client-id.
              Since JMS enforces uniqueness on this client-id, this means that if a durable
              subscriber MDB is deployed to multiple servers only one server will be able
              to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The durable subscription is uniquely identified within a cluster by a
              combination of "connection-id" and "subscription-id". Only one active
              connection may use a particular "connection-id" within a WebLogic cluster.
              The connection id comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              Work-around:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              

  • MDB/Topic/WLS cluster question

              Hi
              I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
              in cluster config where say I have 3 servers with say server#1 hosting the Topic
              [not a distributed destination]. I have an an ear file containing an MDB with
              no pool size limit. After deploying the ear in the cluster - lets say that each
              server on the cluster has 5 instances of the MDB [just an example] and a message
              is published on the Topic.
              Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
              is yes]
              Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
              Q3> Had I had a separate deployment of the same MDB class in the EAR file for
              the same Topic - thats just going to get treated as a completely separate subscriber
              independent of the first MDB though the implementing class is the same - right?
              thanks
              Anamitra
              

              Anamitra wrote:
              > Hi
              > I was going through some WLS 8.1 docs on JMS and had a question abt Topics & WLS
              > in cluster config where say I have 3 servers with say server#1 hosting the Topic
              > [not a distributed destination]. I have an an ear file containing an MDB with
              > no pool size limit. After deploying the ear in the cluster - lets say that each
              > server on the cluster has 5 instances of the MDB [just an example] and a message
              > is published on the Topic.
              >
              > Q1>Will all the 3 servers get a [one and only one] copy of that message? [my guess
              > is yes]
              Yes.
              > Q2>Only 1 instance [out of 5] of the MDB/per server will get the message - right?
              Yes.
              > Q3> Had I had a separate deployment of the same MDB class in the EAR file for
              > the same Topic - thats just going to get treated as a completely separate subscriber
              > independent of the first MDB though the implementing class is the same - right?
              Yes.
              >
              > thanks
              > Anamitra
              >
              For a little more information, I'm attaching notes on durable
              subscriber MDBs.
              A JMS durable subscription is uniquely identified within a cluster by a combination of "connection-id" and "subscription-id". Only one active connection may use a particular "connection-id" within a WebLogic cluster.
              In WebLogic 8.1 and previous, a durable topic subscriber MDB uses its name to generate its client-id. Since JMS enforces uniqueness on this client-id, this means that if a durable subscriber MDB is deployed to multiple servers only one server will be able to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB connection id, which is unique within a cluster, comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The above prevents a durable topic subscriber MDB from running on multiple servers. When an instance of the MDB starts on another server, it deploys successfully, but a conflict is detected and the MDB fails to fully connect to JMS. The work-around is the following:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              4) A copy of each message is sent to each to each server's MDB pool.
              

  • Client Id in use - WL6.1 sp3   server to server JMS messaging

    Any feedback would be greatly appreciated. THANKS!
              -Alan May
              Scenario:
              Two weblogic 6.1 sp3 instances running on two separate Solaris 8 boxes.
              Server a - a message producer(client) for a number of topics and queues on b
              Server b - hosts JMS services including all the topics and queues, has both
              message producers and mdb consumers for a number of topics and queues
              What I've set up: a durable connection factory for topics for server a,
              topics for server b, queues for server a, and queues for server b (all
              targeted to server b)
              I have a singleton on each server that has methods to retrieve the queue
              connection or topic connection appropriate for that server(a single
              connection is
              shared for all topic producers and a separate connection is share for all
              queue producers for each server)
              I have each producer open and close a new session every time. However, the
              topic and queue connections are shared for all producers for that JVM. This
              seemed to be the approach recommended by the JMS spec, but do you feel this
              is the appropriate granularity given the above scenario? I am not currently
              closing my jms connection as part of a weblogic shutdown class. Is that
              essential in that case? If the server crashes - are there any
              recommendations on how to handle(if closing the connection is the issue)?
              I've confirmed that my JMS clients running with server b are not using the
              connection factories setup for a's use.
              Issue:
              Everything works on server b as expected.
              Server a's connections seemed to be fouled. I was getting that the clientid
              was in use(stack trace included below) while trying to fetch the connection.
              I stopped server a, removed the fouled connection factories on server
              b(dedicated for server a's use), and created new connection factories for
              a's use. I stopped server b and deleted everything from the two JMSState
              and JMSStore tables, restarted a then b, and tried the test again. This
              time the singleton code could fetch the connection without receiving a
              JMSException, but I was getting an exception when I tried to open a session
              from the connection.
              If worst comes to worse, I can stick a stateless session bean on b, to act
              as a delegate producer on behalf of server a, but I'd like to avoid it if
              possible.
              Any recommendations? Please let me know if it would be helpful for me to
              clarify any points.
              Server a's original error:
              weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
              is in use
              Start server side stack trace:
              weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
              is in use
              at
              weblogic.jms.frontend.FEConnection.setClientId(FEConnection.java:918)
              at weblogic.jms.frontend.FEConnection.<init>(FEConnection.java:178)
              at
              weblogic.jms.frontend.FEConnectionFactory$1.run(FEConnectionFactory.java:319
              at weblogic.management.internal.Helper.doLocally(Helper.java:1656)
              at
              weblogic.jms.frontend.FEConnectionFactory.connectionCreate(FEConnectionFacto
              ry.java:316)
              at weblogic.jms.frontend.FEConnectionFactory_WLSkel.invoke(Unknown
              Source)
              at
              weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              at
              weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
              :93)
              at
              weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              at
              weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
              2)
              at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              End server side stack trace
              

    Hi Alan,
              Lots of questions in one message! I'm going to
              try and answer them using the shotgun approach -- let
              me know if I miss.
              (1) It is good practice to close JMS resources when you are done
              with them, even if the destination host server crashes. The reason
              is that the connection resource may be hosted on a different
              WL server than the destination.
              (2) Creating a session/producer per message is heavy-weight
              in terms of CPU and network - if your app is performance
              sensitive is is better to cache these resources for re-use.
              See the JMS Performance Guide for details.
              (3) From your description I can't tell which two
              clients are conflicting. If what I'm writing here
              doesn't help, please try to narrow it down and repost.
              (4) Make sure that the connection factory does not have
              a "client-id" configured for it. Otherwise only one client
              can use the connection factory - instead have individual
              clients dynamically set their ids.
              (5) Note that client-ids are usually only useful for
              durable subscriber access, as other types of clients
              generally don't need exclusive connections, and therefore
              don't need client-ids.
              (6) The attached notes, which are for MDBs, may help you
              understand durable subscriptions and client-id's better in general.
              Tom
              Alan May wrote:
              > Any feedback would be greatly appreciated. THANKS!
              >
              > -Alan May
              >
              >
              > Scenario:
              >
              > Two weblogic 6.1 sp3 instances running on two separate Solaris 8 boxes.
              >
              > Server a - a message producer(client) for a number of topics and queues on b
              >
              > Server b - hosts JMS services including all the topics and queues, has both
              > message producers and mdb consumers for a number of topics and queues
              >
              > What I've set up: a durable connection factory for topics for server a,
              > topics for server b, queues for server a, and queues for server b (all
              > targeted to server b)
              >
              > I have a singleton on each server that has methods to retrieve the queue
              > connection or topic connection appropriate for that server(a single
              > connection is
              > shared for all topic producers and a separate connection is share for all
              > queue producers for each server)
              >
              > I have each producer open and close a new session every time. However, the
              > topic and queue connections are shared for all producers for that JVM. This
              > seemed to be the approach recommended by the JMS spec, but do you feel this
              > is the appropriate granularity given the above scenario? I am not currently
              > closing my jms connection as part of a weblogic shutdown class. Is that
              > essential in that case? If the server crashes - are there any
              > recommendations on how to handle(if closing the connection is the issue)?
              >
              > I've confirmed that my JMS clients running with server b are not using the
              > connection factories setup for a's use.
              >
              > Issue:
              > ------
              > Everything works on server b as expected.
              >
              > Server a's connections seemed to be fouled. I was getting that the clientid
              > was in use(stack trace included below) while trying to fetch the connection.
              >
              > I stopped server a, removed the fouled connection factories on server
              > b(dedicated for server a's use), and created new connection factories for
              > a's use. I stopped server b and deleted everything from the two JMSState
              > and JMSStore tables, restarted a then b, and tried the test again. This
              > time the singleton code could fetch the connection without receiving a
              > JMSException, but I was getting an exception when I tried to open a session
              > from the connection.
              >
              > If worst comes to worse, I can stick a stateless session bean on b, to act
              > as a delegate producer on behalf of server a, but I'd like to avoid it if
              > possible.
              >
              > Any recommendations? Please let me know if it would be helpful for me to
              > clarify any points.
              >
              >
              >
              > Server a's original error:
              > weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
              > is in use
              >
              > Start server side stack trace:
              > weblogic.jms.common.InvalidClientIDException: Client id, Parser.topicPrime,
              > is in use
              > at
              > weblogic.jms.frontend.FEConnection.setClientId(FEConnection.java:918)
              > at weblogic.jms.frontend.FEConnection.<init>(FEConnection.java:178)
              > at
              > weblogic.jms.frontend.FEConnectionFactory$1.run(FEConnectionFactory.java:319
              > )
              > at weblogic.management.internal.Helper.doLocally(Helper.java:1656)
              > at
              > weblogic.jms.frontend.FEConnectionFactory.connectionCreate(FEConnectionFacto
              > ry.java:316)
              > at weblogic.jms.frontend.FEConnectionFactory_WLSkel.invoke(Unknown
              > Source)
              > at
              > weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:305)
              > at
              > weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
              > :93)
              > at
              > weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274)
              > at
              > weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:2
              > 2)
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
              > End server side stack trace
              >
              >
              A durable topic subscriber MDB uses its name to generate its client-id.
              Since JMS enforces uniqueness on this client-id, this means that if a durable
              subscriber MDB is deployed to multiple servers only one server will be able
              to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The durable subscription is uniquely identified within a cluster by a
              combination of "connection-id" and "subscription-id". Only one active
              connection may use a particular "connection-id" within a WebLogic cluster.
              The connection id comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              Work-around:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              

  • JMS Durable Distributed Topics

              Please forgive my ignorance if I am doing something silly. I am new to Weblogic
              and JMS, but learning a lot quickly. Any help will be greatly appreciated.
              I am running weblogic 8.1 with no service packs in a development environment only.
              We are trying to work out what is the expected behaviour for our current JMS Topic
              framework.
              I have a two server cluster with distributed topics configured. The two topics
              are configured to be durable. I have a test which generates about 100 events for
              test purposes. Under normal circumstances, each server processes about 50 messages.
              (Load balancing!)
              When the test is running, I kill one of the servers manually before it finishes.
              (Not a gracefull shutdown). The killed server processes about 20 messages, and
              the running server processes about 50. I can see that tables for the persistent
              topics have something (I don't know what) representing about all 100 events sent.
              When I bring the killed server back up, nothing happens. I would expect, from
              the documentation that I read, that the remaining 30 or so events will be put
              on the topic to be processed by our MDBs.
              Why don't all the events get placed on the topic of the killed server when it
              starts back up?
              What is the expected behaviour here?
              Is something wrong with my topic setup?
              Thanks in advance for any help...
              regards,
              Patrick Parato
              

    Hi Patrick,
              Note 1: If you desire MDB to be transactional. Make sure
              the assembly descriptor in ejb-jar.xml is set to
              "Required" in addition to making the transaction-type
              "Container" as you have already done.
              <assembly-descriptor>
              <container-transaction>
              <method>
              <ejb-name>YOUREJBNAME</ejb-name>
              <method-name>onMessage()</method-name>
              </method>
              <trans-attribute>Required</trans-attribute>
              </container-transaction>
              </assembly-descriptor>
              Note 2: Your MDB is non-durable. It needs to be durable
              to cause messages to persist. Add the following line
              in the message-driven-destination clause of your ejb-jar.xml:
              <subscription-durability>Durable</subscription-durability>
              See the JMS FAQ on dev2dev.bea.com (or the JMS Performance
              Guide white-paper) for information on how to make
              sure a message is persistent.
              Note 3: Only one durable subscriber MDB will
              be able to attach to a given durable subscription, MDB's
              on other servers won't be able to, so even if the MDB
              is targeted at the cluster only one MDB will be able
              to process messages. This is the nature
              of durable subscriptions. I'm attaching some personal
              notes on the subject.
              Note 4: Durable subscriptions must refer to
              the JNDI name of member destinations, not to
              the distributed destination. WL does not support
              durable subscriptions directly on a distributed topic.
              Note 5: If you do not want message replication I'm not
              sure why you are using a distributed topic. Use a
              distributed queue.
              Tom
              Patrick Parato wrote:
              > Tom,
              >
              > Thanks for the quick reply.
              >
              > The first thing I want to clarify is that we only have one subscriber (MDB) that
              > is deployed once across multiple servers in a cluster. So this may explain why
              > each server is getting half the messages.
              Its still not clear. Each MDB pool should get each message.
              The individual
              instances in the pool will divide the messages sent to their MDB
              pool's subscription among them.
              >
              >
              >>2) Make sure that you are using durable subscribers. I suspect you
              >>are not. Note that durable subscribers are not supported
              >>for distributed destinations - they must refer directly to a member
              >>destination instead.
              >>
              >
              >
              > We are definitely using a distributed topic. The entry for our MDB in the weblogic-ejb.jar.xml
              > for the <destination-jndi-name> refers to the jndi name of the distributed topic.
              > So if I understand you correctly you are saying that the <destination-jndi-name>
              > should refer to the jndi name of an actual phyiscal topic on one of the servers.
              > By tying an MDB to a regular topic, how do we achieve failover if the JMS server
              > that the topic is associated with should fail?
              >
              >
              >
              > Here is a snippet of our config.xml:
              > (Names have been changed for security reasons)
              >
              > <JMSServer Name="JMS Server1" Store="Event Store1" Targets="myserver1">
              > <JMSTopic CreationTime="1065029382062"
              > JNDIName="distributed.topic@JMS Server1"
              > JNDINameReplicated="false"
              > Name="Distributed Topic@JMS Server1"
              > Template="Distributed Topic" TimeToDeliverOverride="5000"/>
              > </JMSServer>
              >
              > <JMSServer Name="JMS Server2" Store="Event Store2" Targets="myserver2">
              > <JMSTopic CreationTime="1065029382375"
              > JNDIName="distributed.topic@JMS Server2"
              > JNDINameReplicated="false"
              > Name="Distributed Topic@JMS Server2"
              > Template="Distributed Topic" TimeToDeliverOverride="5000"/>
              > </JMSServer>
              >
              >
              > <JMSDistributedTopic JNDIName="distributed.topic" Name="Distributed Topic" Targets="Cluster">
              > <JMSTemplate DeliveryModeOverride="Persistent"
              > Name="Distributed Topic" TimeToDeliverOverride="5000"/>
              > <JMSDistributedTopicMember
              > JMSTopic="distributed.topic@JMS Server1" Name="Distributed Topic@JMS
              > Server1"/>
              > <JMSDistributedTopicMember
              > JMSTopic="distributed.topic@JMS Server2" Name="Distributed Topic@JMS
              > Server2"/>
              > </JMSDistributedTopic>
              >
              >
              > ejb-jar.xml:
              >
              > <message-driven>
              >      <ejb-name>AnMDB</ejb-name>
              >      <ejb-class>package.AnMDB</ejb-class>
              >      <transaction-type>Container</transaction-type>
              >      <message-driven-destination>
              >           <destination-type>
              >                javax.jms.Topic
              >           </destination-type>
              >      </message-driven-destination>
              > </message-driven>
              >
              > weblogic-ejb.jar.xml:
              >
              > <weblogic-enterprise-bean>
              > <ejb-name>AnMDB</ejb-name>
              >      <message-driven-descriptor>
              >      <destination-jndi-name>distributed.topic</destination-jndi-name>
              >      </message-driven-descriptor>
              >      <enable-call-by-reference>True</enable-call-by-reference>
              >      <jndi-name>ejb.AnMDB</jndi-name>
              > </weblogic-enterprise-bean>
              >
              > Thanks for you help and quick reply.
              >
              > regards,
              > Patrick Parato
              >
              A durable topic subscriber MDB uses its name to generate its client-id.
              Since JMS enforces uniqueness on this client-id, this means that if a durable
              subscriber MDB is deployed to multiple servers only one server will be able
              to connect. Some applications want a different behavior where
              each MDB pool on each server gets its own durable subscription.
              The MDB durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The durable subscription is uniquely identified within a cluster by a
              combination of "connection-id" and "subscription-id". Only one active
              connection may use a particular "connection-id" within a WebLogic cluster.
              The connection id comes from:
              1) The "ClientId" attribute configured on the WebLogic connection factory.
              This defaults to null. Note that if the ClientId is set on a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              Work-around:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's connection
              factory to the JNDI name of the custom connection factories configured in
              (A). Optionally, also specify the subscriber-id via the jms-client-id
              attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom connection
              factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's corresponding
              connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory, which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              

  • Topic with Durable Subscription Questions...

              Hello all,
              The scenario: WL 7.0 - sp2, a clustered environment. I have a JMS Topic which
              has one MsgBean that is Durable and one MsgBean that is non-durable consuming
              messages off this Topic. Both MsgBeans are deployed on all machines in the cluster,
              and the server (which contains the topic) is targetted to one machine.
              The issue that I am experiencing is that the DurableMsgBean can not connect to
              the jms topic, but the non-durable one gets its messages all the time.
              Any ideas/suggestions?
              C.
              

    Hi,
              The durable subscriber name is derived from the descriptor's ejb name,
              and only one consumer may attach to a particular durable subscription
              at a time. I've attached some notes that should help you out, please
              excuse the jumbled formatting.
              Let me know if this helps,
              Tom, BEA
              The durable subscription is uniquely identified within a cluster by a
              combination of "connection-id" and "subscription-id". Only one active
              connection may use a particular "connection-id" within a WebLogic cluster.
              The durable subscription id, which must be unique on its topic, comes from:
              1) <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              2) if (1) is not set then the client-id
              comes from the ejb name.
              The connection id comes from:
              1) The "ClientId" attribute configured on the WebLogic
              connection factory.
              This defaults to null. Note that if the ClientId is set on
              a connection
              factory, only one connection created by the factory
              may be active at a time.
              2) If (1) is not set, then, as with the subscriber-id,
              the connection-id is derived from jms-client-id descriptor attribute:
              <jms-client-id>MyClientID</jms-client-id>
              (the weblogic dtd)
              3) If (1) and (2) are not set, then, as with the subscriber-id,
              the connection-id is derived from the ejb name.
              Work-around:
              A) Create a custom connection-factory for each server:
              1) configure "JNDIName" to the same value across all servers
              ("myMDBCF" in this example)
              2) configure "ClientId" to a unique value per server
              3) enable "UserTransactionsEnabled"
              4) enable "XAConnectionFactoryEnabled"
              5) set "AcknowledgePolicy" to "ACKNOWLEDGE_PREVIOUS"
              6) target the CF at a single WebLogic server
              (Number 5 is required for non-transactional topic MDBs)
              B) In the MDB's weblogic-ejb-jar.xml descriptor, set the MDB's
              connection factory to the JNDI name of the custom connection factories
              configured in (A). Optionally, also specify the subscriber-id via the
              jms-client-id attribute.
              <weblogic-ejb-jar>
              <weblogic-enterprise-bean>
              <ejb-name>exampleBean</ejb-name>
              <message-driven-descriptor>
              <connection-factory-jndi-name>myMDBCF</connection-factory-jndi-name>
              <jms-client-id>myClientID</jms-client-id>
              </message-driven-descriptor>
              </weblogic-enterprise-bean>
              </weblogic-ejb-jar>
              C) Target the application at the same servers that have the custom
              connection factories targeted at them.
              Notes/Limitations:
              1) If the MDB is moved from one server to another, the MDB's
              corresponding connection-factory must be moved with it.
              2) This work-around will not work if the destination is not in the same
              cluster as the MDB. (The MDB can not use the local connection factory,
              which
              contains the connection-id, as connection factories do not work unless they
              are in the same cluster as the destination.)
              3) This work-around will not work for non-WebLogic JMS topics.
              csw wrote:
              > Hello all,
              >
              > The scenario: WL 7.0 - sp2, a clustered environment. I have a JMS Topic which
              > has one MsgBean that is Durable and one MsgBean that is non-durable consuming
              > messages off this Topic. Both MsgBeans are deployed on all machines in the cluster,
              > and the server (which contains the topic) is targetted to one machine.
              >
              > The issue that I am experiencing is that the DurableMsgBean can not connect to
              > the jms topic, but the non-durable one gets its messages all the time.
              >
              > Any ideas/suggestions?
              >
              > C.
              >
              

  • JMS connection false

              Hi,
              My EJB with an MDB is deploying but It is showing following error
              EJB:010112]The Message Driven Bean 'sample1' is transacted, but the provider
              defined in the EJB is not transacted. Provider should be transacted if onMessage
              method in MDB is transacted.>
              <Jul 9, 2003 7:05:41 PM PDT> <Warning> <EJB> <BEA-010081> <The message-driven
              bean sample1 was configured to use a JMS Topic, requires container-managed transactions,
              and uses a foriegn JMS provider. Only one thread will be us ed to receive and
              process all messages.>
              My MDB first used a foriegn JMS provider but now I converted it to use the weblogic
              JMS .
              where can be the problem?
              Did I miss something here?
              Thanks
              nlb
              

              Thanks a lot
              Tom
              suggestion no (2) worked
              Tom Barnes <[email protected]> wrote:
              >If your using WL JMS either:
              >
              >(1) Don't specify a connection factory in the weblogic ejb
              >so that the internal default one can be used.
              >
              >or
              >
              >(2) Ensure that the custom connection factory you specified
              >has the "User Transactions Enabled" flag checked, and that
              >the acknowledge policy is changed to "acknowledge before"
              >rather than the default "acknowledge all". The latter
              >step is needed for non-transactional Topic MDBs.
              >
              >Are you getting warning message BEA-010081 even though WebLogic
              >is the JMS provider?
              >
              >Tom, BEA
              >
              >NLB wrote:
              >> Hi,
              >>
              >> My EJB with an MDB is deploying but It is showing following error
              >
              >>
              >> EJB:010112]The Message Driven Bean 'sample1' is transacted, but the
              >provider
              >> defined in the EJB is not transacted. Provider should be transacted
              >if onMessage
              >> method in MDB is transacted.>
              >> <Jul 9, 2003 7:05:41 PM PDT> <Warning> <EJB> <BEA-010081> <The message-driven
              >> bean sample1 was configured to use a JMS Topic, requires container-managed
              >transactions,
              >> and uses a foriegn JMS provider. Only one thread will be us ed to receive
              >and
              >> process all messages.>
              >>
              >> My MDB first used a foriegn JMS provider but now I converted it to
              >use the weblogic
              >> JMS .
              >>
              >> where can be the problem?
              >>
              >> Did I miss something here?
              >>
              >> Thanks
              >>
              >> nlb
              >>
              >>
              >
              

Maybe you are looking for