MDB Transaction

Hi,
I'm having some issues in same cases with MDB transactions on WL. I have an MDB deployed on a 9.2 WL defined as a CMP with auto-acknowledge in the EJB descriptor (using EJB 2.1 standards) which listens on a queue which is defined in the local WL JMS module and mapped to an external Tibco EMS queue.
Used descriptor configuration :
<messaging-type>javax.jms.MessageListener</messaging-type>
<transaction-type>Container</transaction-type>
<message-destination-type>javax.jms.Queue</message-destination-type>
<activation-config>
<activation-config-property>
<activation-config-property-name>destinationType</activation-config-property-name>
<activation-config-property-value>javax.jms.Queue</activation-config-property-value>
</activation-config-property>
<activation-config-property>
<activation-config-property-name>acknowledgeMode</activation-config-property-name>
<activation-config-property-value>Auto-acknowledge</activation-config-property-value>
</activation-config-property>
</activation-config>
The MDB processes the message, accesses a DB and sends it of the an external system. When no exception happened the MDB method finishes and normally the container acknowledges
This all works great untill we put some load on the queue. Sometimes we note that a JMS message gets stuck in the input queue when lots of messages are being put on the input queue. We can trace that such messages actually were picked up by the MDB and processed to a certain extend.
Sometimes the processing log trace just stops in the middle of processing. Sometimes the entire processing log trace is present. However the JMS messages are kept in the input queue and seem to locked (they can't be flushed out as long as the component is still running).
It looks like the messages are awaiting acknowledgement from the WL container manager but somehow the transaction got lost and never got back to the external EMS to acknowledge the message in the input queue.
I was wondering if there is a way to monitor CMP transactions or the status of the container manager? As far as I know the container manager always tries to contact the remote EMS server to acknowledge the message in this setup. What would happen if the remote EMS server would be overloaded and could not respond back to the WL container manager to confirm message acknowledgment?

Thanks for the reply. There are no errors what so ever regarding MDB issues. Not in the weblogic / console logging, nor in the logging of the component itself.
The MDB itself is setup to have 16 concurrent beans per component deployment. The component is clustered over 4 server instances. So there are quite some concurrent MDBs running. However since the messages get stuck for weeks eventhough the component only has bursts of messages to process, one would think that the the stuck messages would be processed whenever the component has some spare time (which it has a lot between the bursts).
Therefor i doubt it has anything to do with too little MDBs running. But frankly I have no idea what's wrong.

Similar Messages

  • MDB transaction attributes

    Is there a special reason why NotSupported and Required are the only two supported transaction attributes? I understand that MDBs cannot have a client-initiated transaction, but there are other transaction attributes that indicate the same thing.
    If an MDB wants to indicate that it should not execute in a transaction, why can't it indicate Never or Supports in addition to NotSupported? In the case of no client-initiated transaction, all three result in the annotated method occuring under no transaction.
    If an MDB wants to indicate that it should execute in a transaction, why can't it indicate RequiresNew in addition to Required? Again, in the case of no client-initiated transaction, both result in the annotated method occuring under a transaction.
    The Mandatory attribute throws an exception if there is no client-initiated transaction, so clearly that is never appropriate for MDBs. But I am confused as to why the other transaction attributes cannot be used as indicated above.
    Please clarify why the specification indicates this about MDB transaction attributes...
    Thanks.

    When ejb webservice endpoints were introduced in J2EE 1.4 there was no support for
    propagation of transaction context over a webservice invocation. Both the JSR 109
    spec and the EJB 2.1 spec prohibited the use of MANDATORY on an ejb web
    service endpoint since using it was likely a developer error.
    In Java EE 5 the restriction against MANDATORY for ejb web service endpoints was removed in the
    EJB 3.0 spec. There's still no requirement that transactions be able to flow with web service
    invocations but there are some products that support it so the ejb container is no longer
    required to throw an exception in that case.
    --ken                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               

  • MDB transaction getting silently rolled back?

              I have an MDB that is doing a delete of a database record in the onMessage method.
              It seems to work fine. I see no errors in the log, in fact I have some debug
              statements that indicate everything was completed normally. I even do a count
              sql using the same where clause and print the results and see a '0'.
              However, when I check the database, the record is still there.
              It seems as if the transaction is getting rolled back somehow. The MDB is transaction
              required/container tx. I never setRollbackOnly anywhere.
              The topic was originally published in a transaction that was rolled back, if that
              makes any difference. In fact, the point of the MDB is to clean up a record that
              was created during the transaction but not within the transaction.
              Any help is appreciated!
              ken
              

              It turned out that the MDB was using a different connection pool than it should
              have, which was pointed to an old copy of the database. So it wasn't really rolling
              back, it really was deleting records as desired, just in the wrong database.
              Thanks
              ken
              Tom Barnes <[email protected].bea.com>
              wrote:
              >Some random ideas:
              >
              >Is the app sending a delete request to the MDB, and
              >the MDB acting on it, before the record is even inserted?
              >
              >Does the delete request have the correct row-id/PK?
              >
              >Is the MDB app failing without your knowledge? You
              >can instrument the MDB onMessage() with a
              >"try catch Throwable" to see.
              >
              >Is the MDB tx timing out trying to get a lock
              >on the row? You can instrument the onMessage
              >with timestamps to see if its taking longer than 30 seconds...
              >
              >Tom
              >
              >Ken Clark wrote:
              >
              >> I have an MDB that is doing a delete of a database record in the onMessage
              >method.
              >> It seems to work fine. I see no errors in the log, in fact I have
              >some debug
              >> statements that indicate everything was completed normally. I even
              >do a count
              >> sql using the same where clause and print the results and see a '0'.
              >>
              >> However, when I check the database, the record is still there.
              >>
              >> It seems as if the transaction is getting rolled back somehow. The
              >MDB is transaction
              >> required/container tx. I never setRollbackOnly anywhere.
              >>
              >> The topic was originally published in a transaction that was rolled
              >back, if that
              >> makes any difference. In fact, the point of the MDB is to clean up
              >a record that
              >> was created during the transaction but not within the transaction.
              >>
              >> Any help is appreciated!
              >>
              >> ken
              >
              

  • MDB Transaction Management Problem

    Hi,
    I am implementing a container managed MDB. The process involves implementing the retry queue and a dead letter queue in case the message is not processed properly.
    In one of the scenarios, an exception gets thrown during the message processing and the message is sent to the retry queue. But somehow it is not being delivered to this queue also and an exception gets thrown. I can see the stacktrace in the logs but somehow This exception is not causing my transaction to rollback in the original MDB and hence the message is getting lost.
    I am using WSAD 5.1 with websphere app server.
    Can someone help please.

    Hi,
              Thanks for your reply.
              Unfortunatelly, I didn't find any information about that issue in Release Notes of Service Pack 5.
              Could you show me any source of information about this problem as it is known issue ?

  • Randomly occurring error while starting MDB transaction

    We have been seeing a strange intermittent problem with MDBs in a clustered WLS 9.1 environment. Our cluster consists of two managed servers, each of which runs on a separate Windows machine, and our application is targeted to both. We use container managed transactions. From time to time, one of the MDBs on the second managed server runs into a problem where it is unable to start a transaction, and the message is automatically transferred to the appropriate JMS error destination before the logic within the onMessage method is even invoked. This results in a situation where our app logs have no record that the message was ever received, so we continually have to go out to the error destinations to see if there are any messages. This problem does not appear to follow any pattern, and occurs randomly with pretty much all of our MDBs on the second server. The stack trace from the log is below. Any help in tracking down the cause of this problem would be greatly appreciated.
    Regards,
    Sabrina
    <Jun 12, 2006 2:02:47 PM EDT> <Error> <JMSClientExceptions> <BEA-055165> <The following exception has occurred:
    java.lang.RuntimeException: [EJB:010166]Error occurred while starting transaction: weblogic.jms.common.JMSException: Unexpected remote responsenull.
    java.lang.RuntimeException: [EJB:010166].
         at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:282)
         at weblogic.jms.client.JMSSession.onMessage(JMSSession.java:3824)
         at weblogic.jms.client.JMSSession.execute(JMSSession.java:3738)
         at weblogic.jms.client.JMSSession$UseForRunnable.run(JMSSession.java:4228)
         at weblogic.work.ServerWorkManagerImpl$WorkAdapterImpl.run(ServerWorkManagerImpl.java:518)
         Truncated. see log file for complete stacktrace
    weblogic.jms.common.JMSException: Unexpected remote responsenull
         at weblogic.jms.dispatcher.DispatcherAdapter.convertToJMSExceptionAndThrow(DispatcherAdapter.java:110)
         at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncTran(DispatcherAdapter.java:53)
         at weblogic.jms.client.JMSSession.acknowledge(JMSSession.java:1775)
         at weblogic.jms.client.JMSSession.associateTransaction(JMSSession.java:1854)
         at weblogic.ejb.container.internal.MDListener.onMessage(MDListener.java:269)
         Truncated. see log file for complete stacktrace
    weblogic.jms.common.JMSException: Unexpected remote responsenull
         at weblogic.jms.dispatcher.Request.handleThrowable(Request.java:63)
         at weblogic.jms.dispatcher.Request.getResult(Request.java:51)
         at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:803)
         at weblogic.messaging.dispatcher.DispatcherImpl.dispatchSyncTran(DispatcherImpl.java:197)
         at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncTran(DispatcherAdapter.java:51)
         Truncated. see log file for complete stacktrace
    weblogic.jms.common.JMSException: Unexpected remote responsenull
         at weblogic.messaging.dispatcher.Request.wrappedFiniteStateMachine(Request.java:758)
         at weblogic.messaging.dispatcher.DispatcherImpl.dispatchSyncTran(DispatcherImpl.java:197)
         at weblogic.jms.dispatcher.DispatcherAdapter.dispatchSyncTran(DispatcherAdapter.java:51)
         at weblogic.jms.client.JMSSession.acknowledge(JMSSession.java:1775)
         at weblogic.jms.client.JMSSession.associateTransaction(JMSSession.java:1854)
         Truncated. see log file for complete stacktrace
    weblogic.jms.common.JMSException: Unexpected remote responsenull
         at weblogic.jms.dispatcher.Request.getAppException(Request.java:42)
         at weblogic.messaging.dispatcher.Request.handleResult(Request.java:529)
         at weblogic.rmi.extensions.AsyncResultFactory$CallbackableResultImpl.setInboundResponse(AsyncResultFactory.java:75)
         at weblogic.rjvm.BasicOutboundRequest$BasicResponseListener.response(BasicOutboundRequest.java:217)
         at weblogic.rjvm.ResponseWithListener.notify(ResponseWithListener.java:25)
         Truncated. see log file for complete stacktrace
    java.lang.ClassCastException: weblogic.rjvm.ClassTableEntry
         at weblogic.rjvm.MsgAbbrevInputStream.readExtendedContexts(MsgAbbrevInputStream.java:216)
         at weblogic.rjvm.ResponseImpl.retrieveThreadLocalContext(ResponseImpl.java:126)
         at weblogic.rjvm.ResponseWithListener.unmarshalReturn(ResponseWithListener.java:43)
         at weblogic.rmi.internal.AsyncResultImpl.getResults(AsyncResultImpl.java:48)
         at weblogic.rmi.internal.AsyncResultImpl.getObject(AsyncResultImpl.java:98)
         Truncated. see log file for complete stacktrace
    >

    Hi Sabrina,
    Did you ever get a solution to this problem?
    We are seeing the same thing on WebLogic 9.1. It started happening in the past week.
    We have the same originating error ..
    java.lang.ClassCastException: weblogic.rjvm.ClassTableEntry
    Many thanks,
    Shane

  • Reg MDB transaction rollback

    i have an MDB deployed on weblogic 8.1 sp6 server. My confusion here is how the MDB handles transaction rollbacks. E.g suppose if the MDB is designed to do the below action.
    1) read an xml message from a jms queue
    2) insert some database records
    3) generate some xml message, post it to some other jms queue
    suppose if step 1 and 2 is completed, and its on step 3, at this point weblogic server shutdowns suddenly, once i restart the server, it reads the xml message again from the jms queue, but this time it errors out, because it finds the data already entered in step 2.
    My question is when the weblogic server shut down while the mdb was at step 3, why didnt it removed all the db entries it made in step 2. This behaviour apears to me as partial rollback. I have given the mdb descriptor below.
    <ejb-jar>
      <enterprise-beans>
        <message-driven>
          <ejb-name>CSS_Response</ejb-name>
          <ejb-class>com.bt.neo.core.utility.appcontroller.transport.mdb.JmsMessageReceiver</ejb-class>
          <transaction-type>Container</transaction-type>
          <acknowledge-mode>auto-acknowledge</acknowledge-mode>
          <message-driven-destination>
            <destination-type>javax.jms.Queue</destination-type>
          </message-driven-destination>
          <env-entry>
            <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value>core-css-response-inbound.xml</env-entry-value>
          </env-entry>
          <env-entry>
            <env-entry-name>ProcessorBeanName</env-entry-name>
            <env-entry-type>java.lang.String</env-entry-type>
            <env-entry-value>transportAdaptor</env-entry-value>
          </env-entry>
          <resource-ref>
            <res-ref-name>jms/faultTo</res-ref-name>
            <res-type>javax.jms.Destination</res-type>
            <res-auth>Container</res-auth>
          </resource-ref>
        </message-driven>
      </enterprise-beans>
      <assembly-descriptor>
        <container-transaction>
          <method>
            <ejb-name>CSS_Response</ejb-name>
            <method-name>onMessage</method-name>
            <method-params>
              <method-param>javax.jms.Message</method-param>
            </method-params>
          </method>
          <trans-attribute>Required</trans-attribute>
        </container-transaction>
      </assembly-descriptor>
    </ejb-jar>Please clear my doubt.
    Edited by: Deepak Dev on 19-Dec-2011 11:01

    General information on message-driven beans can be found here: http://docs.oracle.com/cd/E12840_01/wls/docs103/ejb/message_beans.html
    To transaction configuration is discussed here: http://docs.oracle.com/cd/E12840_01/wls/docs103/ejb/message_beans.html#wp1162058
    Looks like you have to set the transaction-type to Container and the trans-attribute to required. Also see the note:
    - However, if you make this configuration error, the MDB will not run transactionally—if a failure occurs mid-transaction, updates that occurred prior to the failure will not be rolled back.

  • EJB - MDB Transaction

              Hi,
              I am trying to configure a transaction to span between one Stateless EJB and MANY
              JMS Messages sent to a topic consumed via a MDB.
              I have a Stateless EJB Services called copyOffers(List offerIds). For each offerId
              in OfferIds it sends a JMS Message to the CopyOffer Topic. I have one MDB subscribed
              to the Topic that does the work of copying the ONE offer it was provided. I also,
              have configured the JMSReplyTo with a temp. Topic so that all the CopyOfferMDBs
              can notify the Stateless EJB when they are done.
              I want all the EJB and MDB calls to act within ONE transaction. The Stateless
              Session Bean is marked as REQUIRED and the MDB is marked as CONTAINER and also
              REQUIRED.
              Here is what I have done...
              If I mark my JMS Connection Factory as User Transaction Enabled = true... ALL
              the MDB messages are only delivered once the Stateless EJB is commited. Then each
              MDB is in its own transaction.
              I can not get all the MDBs and the EJB to be in ONE transaction whereby if ONE
              MDB failed ALL failed.
              Any ideas?
              Thanks,
              Mike Porter
              

    Cool!
              There is no standard J2EE API or WebLogic J2EE extension
              for handling multiple asynchronous workers
              in the same transaction, but there is a supported non-J2EE
              "back-door". Use the (free) Tuxedo java client's "tpacall()"
              methods, and program your EJBs to be Tuxedo aware. (Tuxedo
              is BEA's "C" based app server, but no Tuxedo server is needed.)
              http://edocs.bea.com/wls/docs81/wtc.html
              I do not know of any customers without a Tuxedo background that
              are doing this. But, if you are interested, the "wtc" newsgroup
              should be able to get you started.
              Tom
              P.S. The alternative is to use multiple transactions, which
              inform some stateful central location when they are done. This
              stateful thing could be an entity bean. This requires extra
              code for failure cases - as it requires code for detecting the
              failures in the first place, code for fixing up the failed
              transaction(s), and for undoing the committed transactions(s).
              This kind of code is generally referred to as
              "compensating transactions", and, as you can imagine, sometimes
              gets pretty hairy pretty fast...
              Mike Porter wrote:
              > I was afraid of that.
              >
              > Any ideas how I can asynchronously handle multiple workers(IE:my offer copiers)
              > in one transaction. I thought JMS would help but I guess not.
              >
              > Thanks,
              >
              > Mike
              >
              > Tom Barnes <[email protected]> wrote:
              >
              >>Hi Mike,
              >>
              >>As with any messaging system, the production of a message can
              >>not participate in the same transaction as the consumption of
              >>a message. The producer's commit call is what makes
              >>the message available for consumption.
              >>
              >>You may want to read the "transactions" chapter of the
              >>JMS Programmer's guide.
              >>
              >>Tom
              >>
              >>
              >>Mike Porter wrote:
              >>
              >>>Hi,
              >>>
              >>>I am trying to configure a transaction to span between one Stateless
              >>
              >>EJB and MANY
              >>
              >>>JMS Messages sent to a topic consumed via a MDB.
              >>>
              >>>I have a Stateless EJB Services called copyOffers(List offerIds). For
              >>
              >>each offerId
              >>
              >>>in OfferIds it sends a JMS Message to the CopyOffer Topic. I have one
              >>
              >>MDB subscribed
              >>
              >>>to the Topic that does the work of copying the ONE offer it was provided.
              >>
              >>I also,
              >>
              >>>have configured the JMSReplyTo with a temp. Topic so that all the CopyOfferMDBs
              >>>can notify the Stateless EJB when they are done.
              >>>
              >>>
              >>>I want all the EJB and MDB calls to act within ONE transaction. The
              >>
              >>Stateless
              >>
              >>>Session Bean is marked as REQUIRED and the MDB is marked as CONTAINER
              >>
              >>and also
              >>
              >>>REQUIRED.
              >>>
              >>>Here is what I have done...
              >>>If I mark my JMS Connection Factory as User Transaction Enabled = true...
              >>
              >>ALL
              >>
              >>>the MDB messages are only delivered once the Stateless EJB is commited.
              >>
              >>Then each
              >>
              >>>MDB is in its own transaction.
              >>>
              >>>I can not get all the MDBs and the EJB to be in ONE transaction whereby
              >>
              >>if ONE
              >>
              >>>MDB failed ALL failed.
              >>>
              >>>Any ideas?
              >>>
              >>>Thanks,
              >>>
              >>>Mike Porter
              >>>
              >>
              >
              

  • 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.

  • Persistence and XA with MDBs

    Hi,
              We currently run WLS 6.1, SP3. We'd like to use Message Driven Beans over MQSeries. Does anyone know what the minimum version of WLS/SP is needed to make this work? Also, is there any clear documentation on the BEA site. I haven't seen anything.
              Thanks,
              Frank
              

    Hi Frank,
              In 6.1 you can use the messaging bridge (with patches) to forward
              the MQ messages transactionally to a WL destination, and then have
              the MDB transactionally read from the WL destination. Otherwise,
              you can use 7.0 to have MQ drive the MDB directly.
              I highly recommend you start by reading this white-paper
              on dev2dev.bea.com:
              "Whitepaper: Using Foreign JMS Providers with WebLogic Server"
              Note that this white-paper does not take into account
              some 8.1 ease-of-use features that simplify
              integration - see the 8.1 release notes for the two following
              JMS features:
              Foreign Vendor Destination Wrappers
              and
              Resource-Reference Pools
              (I may have the names wrong, but don't have time to look
              them up.)
              Note also that the very latest version of MQ provides
              a remote capable XA JMS client. Previous versions only
              supported transactions if the MQ client ran on the same
              server as the MQ server.
              Tom, BEA
              Frank Guerino wrote:
              > Hi,
              >
              > We currently run WLS 6.1, SP3. We'd like to use Message Driven Beans over MQSeries. Does anyone know what the minimum version of WLS/SP is needed to make this work? Also, is there any clear documentation on the BEA site. I haven't seen anything.
              >
              > Thanks,
              >
              > Frank
              >
              

  • Using MDB with IBM MQSeries

              Hi All,
              I want to use MDB with MQSeries as Messaging medium.
              My Weblogic App. server version is 6.0
              I want MDB to get invoked whenever any message comes in MQSeries queue.
              I think 8.1 version provides a option to add external JMS server.
              Is it possible in 6.0 version?
              Please let me know ASAP.
              Waiting for reply!
              Thanks,
              Prasanna Laddha
              

    Hi Prasanna,
              The best resource is the white-paper, which mentions MQ directly:
              http://dev2dev.bea.com/resourcelibrary/whitepapers/jmsproviders.jsp
              But it does not take into account the following 8.1 feature:
              http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_config.html#accessing_foreign_providers
              Tom
              prasanna wrote:
              > Hi Tom,
              > I had weblogic 7 now.
              > Is there any document which can help me in setting up connection with MQSeries
              > for MDB beans?
              >
              > Pls let me know ASAP.
              > Thanks lot.
              > Prasanna
              >
              >
              >
              > Tom Barnes <[email protected]> wrote:
              >
              >>In 6.0, for non-transactional case, I'm fairly
              >>sure that you can drive the MDB directly from MQ. See
              >>the white-paper:
              >>
              >>http://dev2dev.bea.com/resourcelibrary/whitepapers/jmsproviders.jsp
              >>
              >>But, as with most customers, my guess is that you need
              >>to transfer the messages transactionally
              >>(exactly-once). In which case more work is needed:
              >>
              >>By far the easiest option is to upgrade to WL7.0 or
              >>WL8.1 which can drive an MDB transactionally
              >
              >>from MQ directly. WL8.1 provides enhancements
              >
              >>to wrap foreign vendor resources to simplify
              >>the process even farther.
              >>
              >>Another option is to use a WL6.1SP3 or later
              >>server running a messaging bridge to bridge from MQ
              >>to WL6.0. I'm not sure if these are capable of
              >>bridging to 6.0 exactly-once (transactionally) though.
              >>
              >>For the transactional case, I think you will
              >>end up needing to
              >>write your own "bridge" that runs from within
              >>a startup class or servlet.
              >>The following example shows how to bridge from
              >>wl to mqseries transactionally using a startup class.
              >>To drive the MDB exactly-once, you will need
              >>modify this code to do bridge from MQ into
              >>a WL queue instead, then the queue in turn can
              >>be used to drive the WL MDB:
              >>
              >>http://dev2dev.bea.com/codelibrary/code/mqseries.jsp
              >>
              >>Tom
              >>
              >>
              >>Prasanna wrote:
              >>
              >>>Hi All,
              >>>I want to use MDB with MQSeries as Messaging medium.
              >>>My Weblogic App. server version is 6.0
              >>>
              >>>I want MDB to get invoked whenever any message comes in MQSeries queue.
              >>>I think 8.1 version provides a option to add external JMS server.
              >>>Is it possible in 6.0 version?
              >>>
              >>>Please let me know ASAP.
              >>>Waiting for reply!
              >>>Thanks,
              >>>Prasanna Laddha
              >>>
              >>
              >
              

  • How to design Distributed transaction?

    Hi
    I have distributed transaction that involve MQ and two oracle database. In both database I have stroed procedure that have their own rollback points. My requirement is that either both database shoulb committed or none.
    For this to implement I have a MDB that calls SP on first database and without commiting any thing it comes back to MDB and again Calls SP on second database and again come back to MDB and call1 SP on database1..
    But problem is when I am calling 2nd database SP and if any thing goes wrong inside SP then its implicit rollback is not working. To overcome this I put this 2nd database logic in another EJB with RequiresNew. But then problem is that if MDB transaction is rolled back then 2nd database transaction is not getting roollbacked.
    Please suggest any solution to overcome this.
    Server is Websphere 6.0
    Database is: Oracle 10g
    Datasource: XA
    Q: MQ 6.0
    Thanks

    I think you can use Java Trasaction API that is independent of the Resources and will give you more flexibility to handle trasactions
    This link may be helpful
    http://www.onjava.com/pub/a/onjava/2001/05/23/j2ee.html

  • WLS MDB and MQ Series

    Hi ,
              I have an MDB deployed under WLS6.1 which is listening to a WLS
              JMS Queue and the MDB(which calls a MQ Client) has to deliver the
              message to MQ Server once it recieves a message from WLS JMS Queue .
              Now how do I enable the JDBC store to take the messages which fail on
              the MDB side assuming the MQ Server is failing and the MDB should
              retry it again. Or what is the best solution in this scenario without
              using any transactional object . Any suggestions pls about .
              thanks
              taniga s
              

    Approach One:
              Could you have a three bridges all reading the queue, one for each target MQ server?
              This would not be fail-over, but may solve your problem - as it is high-availability.
              (Bridges automatically attempt reconnect on failure.)
              Approach Two:
              Could you forward the message using error destinations, this
              is a feature in 6.1 that redirects recovered or rolled back messages
              to an error destination:
              Q1, error dest is ERROR1, set redeliveryLimit to 0
              ERROR1 error dest is ERROR2, set redeliveryLimit to 0
              ERROR2 error dest is ERROR3, set redelivery limit to 0
              MDB on Q1 goes to MQ queue A
              MDB on ERROR1 goes to MQ queue B
              MDB on ERROR3 goes to JDBC
              taniga wrote:
              > Hi Tom,
              > Thanks a lot and I appreciate your help on this. Actually my
              > situation is kinda different. Our MDB has to be looking for
              > alternative MQ Servers if one is failing and hence we cannot bind the
              > MDB to just a single Queue. So I think i cannot utilize the Bridging
              > btwn MQ and WLS JMS.My aim is like I have to handle the error when MQ
              > Server is down and I should be able to route it to another MQ Server.
              > And in this case too if it fails I should be able to take this message
              > to JDBC Store(considering MDB could not deliver the message to MQ
              > Server). I hope this one explains my problem.
              >
              > thanks
              > taniga s
              >
              > Tom Barnes <[email protected]> wrote in message news:<[email protected]>...
              > > Probably the best solution is to use a bridge to automatically
              > > forward messages between WL and MQ. See the
              > > post on "How to use IBM MQ as a JMS Provider".
              > >
              > > Some possible solutions:
              > >
              > > 1 MDB could accept the message and resend it to its WLS queue with
              > > a birth-time (time-to-deliver) for later retry.
              > >
              > > 2 MDB could reject message (by throwing a runtime exception, such
              > > as NullPointerException). WL behavior here is to call recover() and
              > > resend message. (Alternatively make the MDB transactional and set
              > > rollback-only.) To prevent message from being immediately
              > > redelivered, configure a redelivery delay on the destination.
              > >
              > > 3 MDB could be undeploy self on failure, and a timer object or some such
              > > thing could be initiated to redeploy MDB once it detects
              > > MQ dest comes up.
              > >
              > > Redelivery delay and time-to-deliver are both WL extensions. They
              > > are described in detail in the JMS programmer's guide.
              > >
              > > taniga wrote:
              > >
              > > > Hi ,
              > > > I have an MDB deployed under WLS6.1 which is listening to a WLS
              > > > JMS Queue and the MDB(which calls a MQ Client) has to deliver the
              > > > message to MQ Server once it recieves a message from WLS JMS Queue .
              > > > Now how do I enable the JDBC store to take the messages which fail on
              > > > the MDB side assuming the MQ Server is failing and the MDB should
              > > > retry it again. Or what is the best solution in this scenario without
              > > > using any transactional object . Any suggestions pls about .
              > > >
              > > > thanks
              > > > taniga s
              

  • XA datasource autocommit is false when no transaction context

    WLS 8.1SP4
    I am usign MS SQL Serevr JDBC driver.
    I use the XA driver: com.microsoft.jdbcx.sqlserver.SQLServerDataSource
    I have an MDB, transaction not supported.
    The MDB gets a connection from an xa datasource which maps to that SQL Server XA driver.
    Even thogh the txn is not supported, autocommit is set to TRUE in the connection. I want it false. I know that I can use a non-txnal DS, but why is autocommut false when I have transaction context?
    Kind Regards,
    Graham.

    grahamh wrote:
    WLS 8.1SP4
    I am usign MS SQL Serevr JDBC driver.
    I use the XA driver: com.microsoft.jdbcx.sqlserver.SQLServerDataSource
    I have an MDB, transaction not supported.
    The MDB gets a connection from an xa datasource which maps to that SQL Server XA driver.
    Even thogh the txn is not supported, autocommit is set to TRUE in the connection. I want it false. I know that I can use a non-txnal DS, but why is autocommut false when I have transaction context?
    Kind Regards,
    Graham.Hi Graham. You are correct. This is a bug we have fixed.
    Please contact support and ask for the sp4 patch for
    CR212051.
    Joe

  • MDB tx processing question

    Tom,
    My understanding was that WebLogic by default configuration would pull n messages at a time from the a foreign jms server (via JMS connection poller) ; and process the n messages using the same MDB in n different transactions. Is this correct?
    If it is , what would be the conditions when the message would just stay in WebLogic layer - and weblogic MDB will continuously try to process the message - assuming the code in MDB called setRollbackOnly upon processing failure within the MDB. MDB is transactional.
    We see a thread that seems to sit in the state below in our application - no matter how many threaddumps I take the thread stays at this point. I see no other thread waiting on a lock for anything. But this seemingly stuck thread is causing 5 messages on Tibco EMS to stay in pending state until I shutdown the WLS node - which then breaks the tibco session and tibco then makes the messages available for redelivery and another WLS instance picks it up. Do note that WLS does not report any stuck threads either (stuck thread timeout set to 600 seconds) and my threaddumps span across 5 seconds to 45 minutes.
    "ContinuousJMSMessagePoller :MessageProcessor-Tes-Mts" id=4973 idx=0xde tid=1717 prio=5 alive, daemon
    at java/util/HashMap.get(HashMap.java:344)[optimized]
    at org/jboss/cache/UnversionedNode.getDirect(UnversionedNode.java:203)[inlined]
    at org/jboss/cache/invocation/NodeInvocationDelegate.getDirect(NodeInvocationDelegate.java:212)[optimized]
    at org/jboss/cache/CacheImpl._get(CacheImpl.java:702)[optimized]
    at sun/reflect/GeneratedMethodAccessor176.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)[optimized]
    at sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[optimized]
    at java/lang/reflect/Method.invoke(Method.java:585)[optimized]
    at org/jgroups/blocks/MethodCall.invoke(MethodCall.java:330)
    at org/jboss/cache/interceptors/CallInterceptor.invoke(CallInterceptor.java:53)
    at org/jboss/cache/interceptors/Interceptor.nextInterceptor(Interceptor.java:111)
    at org/jboss/cache/interceptors/EvictionInterceptor.handleGetKeyValueMethod(EvictionInterceptor.java:200)
    at org/jboss/cache/interceptors/MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:84)[optimized]
    at org/jboss/cache/interceptors/Interceptor.nextInterceptor(Interceptor.java:111)
    at org/jboss/cache/interceptors/PessimisticLockInterceptor.handleGetKeyValueMethod(PessimisticLockInterceptor.java:347)
    at org/jboss/cache/interceptors/MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:84)[optimized]
    at org/jboss/cache/interceptors/PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:81)
    at org/jboss/cache/interceptors/Interceptor.nextInterceptor(Interceptor.java:111)[inlined]
    at org/jboss/cache/interceptors/MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:58)[optimized]
    at org/jboss/cache/interceptors/Interceptor.nextInterceptor(Interceptor.java:111)
    at org/jboss/cache/interceptors/TxInterceptor.handleNonTxMethod(TxInterceptor.java:456)
    at org/jboss/cache/interceptors/TxInterceptor.handleGetKeyValueMethod(TxInterceptor.java:250)
    at org/jboss/cache/interceptors/MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:84)[optimized]
    at org/jboss/cache/interceptors/Interceptor.nextInterceptor(Interceptor.java:111)
    at org/jboss/cache/interceptors/CacheMgmtInterceptor.handleGetKeyValueMethod(CacheMgmtInterceptor.java:81)
    at org/jboss/cache/interceptors/MethodDispacherInterceptor.invoke(MethodDispacherInterceptor.java:84)[optimized]
    at org/jboss/cache/interceptors/Interceptor.nextInterceptor(Interceptor.java:111)
    at org/jboss/cache/interceptors/InvocationContextInterceptor.invoke(InvocationContextInterceptor.java:73)
    at org/jboss/cache/invocation/AbstractInvocationDelegate.invoke(AbstractInvocationDelegate.java:123)
    at org/jboss/cache/invocation/AbstractInvocationDelegate.invoke(AbstractInvocationDelegate.java:64)
    at org/jboss/cache/invocation/CacheInvocationDelegate.get(CacheInvocationDelegate.java:382)
    at com/myapp/core/CacheService.get(CacheService.java:188)
    at com/myapp/core/CacheService.getFinancialInstrument(CacheService.java:273)
    at com/myapp/util/TradeDalUtils.lookupFinancialInstrument(TradeDalUtils.java:768)
    at com/myapp/xom/ReferenceData.getFinancialInstrumentByIdentifier(ReferenceData.java:330)
    at com/myapp/xom/CMMExecutionModel.getFiForPrimaryExecutionItem(CMMExecutionModel.java:1170)
    at sun/reflect/GeneratedMethodAccessor57908.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;(Unknown Source)
        at sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)[optimized]
    at java/lang/reflect/Method.invoke(Method.java:585)[optimized]
    at ilog/rules/inset/IlrExecMethodValue.getValue(Lilog/rules/inset/IlrMatchContext;)Ljava/lang/Object;(Unknown Source)
    at ilog/rules/inset/IlrExecNaryValue.a(Lilog/rules/inset/IlrMatchContext;)[Ljava/lang/Object;(Unknown Source)[optimized]
    at ilog/rules/inset/IlrExecNaryValue.a(ILjava/lang/Class;Lilog/rules/inset/IlrMatchContext;)[Ljava/lang/Object;(Unknown Source)
        at ilog/rules/inset/IlrExecStaticMethodValue.getValue(Lilog/rules/inset/IlrMatchContext;)Ljava/lang/Object;(Unknown Source)
        at ilog/rules/inset/IlrExecStoreValue.getValue(Lilog/rules/inset/IlrMatchContext;)Ljava/lang/Object;(Unknown Source)
        at ilog/rules/inset/IlrExecBinaryTest.evaluate(Lilog/rules/inset/IlrMatchContext;)Z(Unknown Source)
        at ilog/rules/inset/IlrExecAndTest.evaluate(Lilog/rules/inset/IlrMatchContext;)Z(Unknown Source)
        at ilog/rules/engine/IlrTestRuleMem.i(Lilog/rules/engine/IlrPartial;)Z(Unknown Source)
        at ilog/rules/engine/IlrTestRuleMem.if(Lilog/rules/engine/IlrPartial;IIJ)Lilog/rules/engine/IlrRuleInstance;(Unknown Source)
        at ilog/rules/engine/IlrDefaultRuleMem.aa()V(Unknown Source)
        at ilog/rules/engine/IlrRuleMem.T()V(Unknown Source)
        at ilog/rules/engine/IlrAgenda.a([Lilog/rules/engine/IlrRule;Lilog/rules/engine/IlrAgendaFilter;IZ)I(Unknown Source)[optimized]
    at ilog/rules/engine/IlrEngine.fireAgendaRules([Lilog/rules/engine/IlrRule;Lilog/rules/engine/IlrAgendaFilter;IZ)I(Unknown Source)[inlined]
    at ilog/rules/inset/IlrExecRuleTask.a(Lilog/rules/engine/IlrTaskEngine;)V(Unknown Source)[inlined]
    at ilog/rules/inset/IlrExecRuleTask.execute(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)V(Unknown Source)[optimized]
    at ilog/rules/inset/IlrExecTask.run(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)V(Unknown Source)[optimized]
    at ilog/rules/engine/IlrTaskEngine.execute(Lilog/rules/inset/IlrExecTaskInstance;Lilog/rules/engine/IlrWorkItem;ZZ)I(Unknown Source)
    at ilog/rules/inset/IlrExecTaskInstance.execute(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)I(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.executeItem(Lilog/rules/engine/IlrWorkItem;Lilog/rules/inset/IlrExecFlowNode;ZZ)I(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.executeSubFlow(Lilog/rules/inset/IlrExecFlowNode;Z)I(Unknown Source)
    at ilog/rules/inset/IlrExecFlowTask.execute(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)V(Unknown Source)
    at ilog/rules/inset/IlrExecTask.run(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)V(Unknown Source)[optimized]
    at ilog/rules/engine/IlrTaskEngine.execute(Lilog/rules/inset/IlrExecTaskInstance;Lilog/rules/engine/IlrWorkItem;ZZ)I(Unknown Source)
    at ilog/rules/inset/IlrExecTaskInstance.execute(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)I(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.executeItem(Lilog/rules/engine/IlrWorkItem;Lilog/rules/inset/IlrExecFlowNode;ZZ)I(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.executeSubFlow(Lilog/rules/inset/IlrExecFlowNode;Z)I(Unknown Source)
    at ilog/rules/inset/IlrExecFlowTask.execute(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)V(Unknown Source)
    at ilog/rules/inset/IlrExecTask.run(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)V(Unknown Source)[optimized]
    at ilog/rules/engine/IlrTaskEngine.execute(Lilog/rules/inset/IlrExecTaskInstance;Lilog/rules/engine/IlrWorkItem;ZZ)I(Unknown Source)
    at ilog/rules/inset/IlrExecTaskInstance.execute(Lilog/rules/engine/IlrTaskEngine;Lilog/rules/engine/IlrWorkItem;ZZ)I(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.executeItem(Lilog/rules/engine/IlrWorkItem;Lilog/rules/inset/IlrExecFlowNode;ZZ)I(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.if(Z)V(Unknown Source)
    at ilog/rules/engine/IlrTaskEngine.a(Z)V(Unknown Source)
    at ilog/rules/engine/IlrContext.a(Z)Lilog/rules/engine/IlrParameterMap;(Unknown Source)
    ^-- Holding lock: ilog/rules/engine/IlrContext@0x1393f318[recursive]
    at ilog/rules/engine/IlrContext.execute()Lilog/rules/engine/IlrParameterMap;(Unknown Source)
    ^-- Holding lock: ilog/rules/engine/IlrContext@0x1393f318[recursive]
    at ilog/rules/bres/xu/spi/IlrEngineManager.execute()Ljava/util/Map;(Unknown Source)
    ^-- Holding lock: ilog/rules/engine/IlrContext@0x1393f318[thin lock]
    at ilog/rules/bres/xu/spi/IlrTransactionalEngineManager.execute()Ljava/util/Map;(Unknown Source)
    ^-- Holding lock: ilog/rules/bres/xu/spi/IlrTransactionalEngineManager@0x13897c90[thin lock]
    at ilog/rules/bres/xu/spi/IlrManagedXUConnection.contextExecute(Lilog/rules/bres/xu/cci/IlrXUConnection;)Ljava/util/HashMap;(Unknown Source)
    at ilog/rules/bres/xu/cci/IlrXUConnection.contextExecute()Ljava/util/HashMap;(Unknown Source)
    at ilog/rules/bres/xu/cci/IlrXUInteraction.contextExecute(Ljavax/resource/cci/Record;Ljavax/resource/cci/Record;)Z(Unknown Source)[inlined]
    at ilog/rules/bres/xu/cci/IlrXUInteraction.dispatchExecution(Ljava/lang/String;Ljavax/resource/cci/InteractionSpec;Ljavax/resource/cci/Record;Ljavax/resource/cci/Record;)Z(Unknown Source)[inlined]
    at ilog/rules/bres/xu/cci/IlrXUInteraction.execute(Ljavax/resource/cci/InteractionSpec;Ljavax/resource/cci/Record;Ljavax/resource/cci/Record;)Z(Unknown Source)[inlined]
    at ilog/rules/bres/xu/cci/IlrXUInteraction.execute(Ljavax/resource/cci/InteractionSpec;Ljavax/resource/cci/Record;)Ljavax/resource/cci/Record;(Unknown Source)[optimized]
    at ilog/rules/bres/session/IlrRuleSessionExecuteImpl.executeInteraction(Ljavax/resource/cci/Interaction;Ljavax/resource/cci/Record;Lilog/rules/bres/session/IlrRuleSessionExecuteImpl$Warnings;)Ljavax/resource/cci/Record;(Unknown Source)
    at ilog/rules/bres/session/IlrRuleSessionExecuteImpl.execute(Ljavax/resource/cci/ConnectionFactory;Ljava/lang/String;Ljava/util/Map;Lilog/rules/bres/session/IlrRuleSessionExecuteImpl$Warnings;ZZLjavax/resource/cci/Interaction;)Ljava/util/HashMap;(Unknown Source)
    at ilog/rules/bres/session/IlrRuleSessionExecuteImpl.executeStateless(Ljavax/resource/cci/ConnectionFactory;Ljavax/resource/cci/Connection;Ljavax/resource/cci/Interaction;Lilog/rules/bres/session/IlrSessionRequest;Lilog/rules/bres/session/IlrRuleSessionExecuteImpl$Warnings;)Lilog/rules/bres/session/IlrSessionResponse;(Unknown Source)
    at ilog/rules/bres/session/ejb/IlrStatelessRuleSessionEJB.executeRules(Lilog/rules/bres/session/IlrSessionRequest;)Lilog/rules/bres/session/IlrSessionResponse;(Unknown Source)
    at ilog/rules/bres/session/ejb/IlrStatelessRuleSessionEJB_ugt9ms_ELOImpl.executeRules(IlrStatelessRuleSessionEJB_ugt9ms_ELOImpl.java:145)
    at ilog/rules/bres/session/ejb/IlrGateLocal.executeRules(Lilog/rules/bres/session/IlrSessionRequest;)Lilog/rules/bres/session/IlrSessionResponse;(Unknown Source)
    at com/myapp/rules/jrules/JRuleSession.executeRules(JRuleSession.java:79)
    at com/myapp/core/RuleInvoker.invokeRule(RuleInvoker.java:52)
    at com/myapp/core/statemachine/StateMachine.executeRule(StateMachine.java:143)
    at com/myapp/core/statemachine/StateMachine.doTransition(StateMachine.java:109)
    at com/myapp/core/statemachine/StateMachine.doStateMachineTransitions(StateMachine.java:87)
    at com/myapp/core/statemachine/StateMachine.doTransition(StateMachine.java:64)
    at com/myapp/core/messagehandler/tes/TesMessageHandler.doTESMessageProcessing(TesMessageHandler.java:263)
    at com/myapp/core/messagehandler/tes/TesMessageHandler.tesProcessing(TesMessageHandler.java:134)
    at com/myapp/core/messagehandler/tes/TesMessageHandler.process(TesMessageHandler.java:112)
    at com/myapp/core/FullReSequenceMessageProcessor.doStateMachine(FullReSequenceMessageProcessor.java:173)
    at com/myapp/core/FullReSequenceMessageProcessor.processMessage(FullReSequenceMessageProcessor.java:333)
    at com/myapp/core/MessageProcessorMDB.onMessage(MessageProcessorMDB.java:81)
    at weblogic/ejb/container/internal/MDListener.execute(MDListener.java:429)[inlined]
    at weblogic/ejb/container/internal/MDListener.transactionalOnMessage(MDListener.java:335)[inlined]
    at weblogic/ejb/container/internal/ContinuousJMSMessagePoller.processOneMessage(ContinuousJMSMessagePoller.java:129)[optimized]
    at weblogic/ejb/container/internal/JMSMessagePoller.pollContinuously(JMSMessagePoller.java:394)
    at weblogic/ejb/container/internal/ContinuousJMSMessagePoller.pollForChild(ContinuousJMSMessagePoller.java:185)
    at weblogic/ejb/container/internal/JMSMessagePoller.run(JMSMessagePoller.java:530)
    at java/lang/Thread.run(Thread.java:595)
    at jrockit/vm/RNI.c2java(IIII)V(Native Method)
    -- end of trace
    Edited by: user1631781 on Jun 9, 2010 10:05 AM

    My understanding was that WebLogic by default configuration would pull n messages at a time from the a foreign >jms server (via JMS connection poller) ; and process the n messages using the same MDB in n different >transactions. Is this correct? Its possible for MDB to process more than one message in a transaction using a weblogic specific feature called MDB Transaction batching.This depends on the max-messages-in-transactions descriptor in weblogic-ejb-jar.xml. This controls mdb transaction batch size.
    http://download.oracle.com/docs/cd/E15051_01/wls/docs103/ejb/message_beans.html#wp1161543
    In your case the thread seems to be stuck at the application code level. I doubt if it is related to transactions.
    at java/util/HashMap.get(HashMap.java:344)[optimized]
    at org/jboss/cache/UnversionedNode.getDirect(UnversionedNode.java:203)[inlined]

  • Will weblogic support 2 Phase support for MDB (Container Managed)

    The Transaction is not rolling back when i am throwing an EJB exception during the update of the database
              Followed the below steps
              0) Created a XAConnectionPool (Oracle XA thin Driver)
              1) Created a DataSource for the above pool
              2) Created a QueueConnection factory with XA checked
              3) Deployed a MDB with Transaction Support as Required
              4) When the Database is throwing an exception the message is not rolled back /
              Any idea why this is happening?Will Weblogic 81 supports Container Management for MDB for 2PC transactions?
              i have Oracle driver in the weblogic start classpath and using getting the connection to the DB from the weblogic pool

    - Of course WebLogic supports 2PC - and has for years.
              - There's no need to configure a JMS connection factory - the MDB's default choice is transaction capable.
              - See MDB doc for details on how to configure transactional MDBs.
              (hint: two descriptor settings are required)
              http://edocs.bea.com/wls/docs81/ejb/message_beans.html
              - FYI: You may want to consider upgrading to 9.1:
              * Can pause MDBs
              * Can pause destinations
              * Can view individual messages on the console
              * much higher file store performance
              * JDBC LLR option (faster than pure XA 2PC)
              * MDB transaction batching (speeds up XA - documentation is missing but will be in place soon)

Maybe you are looking for