Foreign JMS and Enlisting Transactions?

I'm working on implementing an XA interface layer to an implementation of a foreign JMS provider and am having a problem with enlisting XA transactions in WebLogic.
          I implemented a simple JNDI that stores and retrieves serialized versions of classes in the local filesystem.
          I create an XATopicConnectionFactory named ambxatcf and a Topic named ChatterTopic and store them in there.
          The XATopicConnection implements XAConnection.
          I put a client jar in bea/weblogic91/samples/domains/wl_server/lib/ which contains the JNDI code and all of my XA classes which call the JMS.
          That gets picked up by the server on startup.
          In the Web Logic Admin Console:
          I create a Foreign Server under JMS Modules, ambrosiaServer.
          I set the JNDI Initial Context Factory set to my JNDI InitialContext class and the JNDI Properties is the path to my JNDI filestore so that it can find the serialized objects.
          I create a Foreign Destination in this server which has a Local JNDI Name: Chatter and Remote JNDI Name: ChatterTopic
          And then also in this server, I create a Foreign Connection Factory, Local JNDI Name: ambxatcf and Remote JNDI Name: XATopicConnectionFactory.
          Then in Deployments, I Install the jar containing my bean and Start it.
          Then I run the client and the bean prints out the XATopicConnectionFactory and it's the one that came out my JNDI.
          I have messages in my XATopicConnectionFactory, XATopicConnection and XATopicSession code so I know they're getting called.
          What's not getting called is XATopicSession.getXAResource() or my XAResourceImpl.start() or XAResourceImpl.commit().
          This happens whether I have the bean set up for bean managed or container managed transactions.
          I'm testing against WebLogic 9.1.
          Thanks,
          Don Hermes

Hi Tom,
          Thank you for your response.
          I saw the article in the 8.1 documentation but I also found the following in the 9.1 docs.
          So, I assumed it would work.
          Was that assumption wrong?
          Thanks,
          Don
          =====================
          http://e-docs.bea.com/wls/docs91/jms/j2ee.html
          Automatically Enlisting Transactions
          This feature works for either WebLogic JMS implementations or for third-party JMS providers that support two-phase commit transactions (XA protocol). If a wrapped JMS connection sends or receives a message inside a transaction context, the JMS session being used to send or receive the message is automatically enlisted in the transaction through the XA capabilities of the JMS provider. This is the case whether the transaction was started implicitly because the JMS code was invoked inside an EJB with container-managed transactions enabled, or whether the transaction was started manually using the UserTransaction interface in a servlet or an EJB that supports bean-managed transactions.

Similar Messages

  • Foreign JMS not enlisting XA Transactions

    I'm working on implementing an XA interface layer to an implementation of a foreign JMS provider and am having a problem with enlisting XA transactions in WebLogic.
    I implemented a simple JNDI that stores and retrieves serialized versions of classes in the local filesystem.
    I create an XATopicConnectionFactory named ambxatcf and a Topic named ChatterTopic and store them in there.
    The XATopicConnection implements XAConnection.
    I put a client jar in bea/weblogic91/samples/domains/wl_server/lib/ which contains the JNDI code and all of my XA classes which call the JMS.
    That gets picked up by the server on startup.
    In the Web Logic Admin Console:
    I create a Foreign Server under JMS Modules, ambrosiaServer.
    I set the JNDI Initial Context Factory set to my JNDI InitialContext class and the JNDI Properties is the path to my JNDI filestore so that it can find the serialized objects.
    I create a Foreign Destination in this server which has a Local JNDI Name: Chatter and Remote JNDI Name: ChatterTopic
    And then also in this server, I create a Foreign Connection Factory, Local JNDI Name: ambxatcf and Remote JNDI Name: XATopicConnectionFactory.
    Then in Deployments, I Install the jar containing my bean and Start it.
    Then I run the client and the bean prints out the XATopicConnectionFactory and it's the one that came out my JNDI.
    I have messages in my XATopicConnectionFactory, XATopicConnection and XATopicSession code so I know they're getting called.
    What's not getting called is XATopicSession.getXAResource() or my XAResourceImpl.start() or XAResourceImpl.commit().
    This happens whether I have the bean set up for bean managed or container managed transactions.
    I'm testing against WebLogic 9.1.
    Thanks,
    Don Hermes

    Hi Tom,
              Thank you for your response.
              I saw the article in the 8.1 documentation but I also found the following in the 9.1 docs.
              So, I assumed it would work.
              Was that assumption wrong?
              Thanks,
              Don
              =====================
              http://e-docs.bea.com/wls/docs91/jms/j2ee.html
              Automatically Enlisting Transactions
              This feature works for either WebLogic JMS implementations or for third-party JMS providers that support two-phase commit transactions (XA protocol). If a wrapped JMS connection sends or receives a message inside a transaction context, the JMS session being used to send or receive the message is automatically enlisted in the transaction through the XA capabilities of the JMS provider. This is the case whether the transaction was started implicitly because the JMS code was invoked inside an EJB with container-managed transactions enabled, or whether the transaction was started manually using the UserTransaction interface in a servlet or an EJB that supports bean-managed transactions.

  • Foreign JMS and XA

    Hi everybody,
              Is anybody successfully using remote IBM MQseries 5.3 server as
              Foreign JMS in WLS 8.1sp2?
              We're observing some strange behavior in this case. Here is our setup:
              WLS and IBM MQ server deployed on separate boxes.
              WLS version 8.1sp2 running on Windows 2000/Intel
              IBM MQ version 5.3 running on Solaris/SPARC
              We're using "WebSphere MQ classes for Java, version 5.303 - j5303-L030225"
              and "WebSphere MQ Extended Transactional Client Feature, version 5.300 -
              j5303-L030122"
              MQ files added in WLS POST_CLASSPATH variable in WLS starup script.
              Foreign JMS server configured in WLS via fscontext JNDI.
              MDB bean deployed with Transaction attribute "Required".
              Everything seems to work fine, if we're posting message to MQ queue MDB
              receives it and process successfully (just print message content to the
              console for now).
              Problem: In WLS console, under Server->Monitoring->JTA->Monitor inflight
              transactions we can constantly see one transaction enlisted for our MDB
              bean with following details:
              =====================================================
              Transaction ID: BEA1-00DFC5EB4B7B7F28EDB9
              Coordinator: mydomain+myserver
              Name: JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              Status: Active
              Seconds Active: 17
              Resources:
              weblogic.ejb20.JMSConnectionPoller.xxx.xxx.MyMessageProcessorMdb=started
              Properties
              (key=value):
              weblogic.transaction.name=JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              =====================================================
              This transaction seems to be Active for 30 seconds and then rolled back
              (no error messages on WLS console displayed).On JTA statistics page in
              WLS console "Total Rolled Back" counter keeps increneting with every
              rollback.
              Does anybody observerd similar problem? May be it's normal behaviour but
              I'm kind of worrying about those transactions and constant rollback. I'd
              appreciate any feedback.
              Sincerely,
              Dmitri Maximovich
              

    Hi Dmitri,
              The shutdown "suspend" failure has nothing to do with transactions
              or JMS. It looks like the failure is due to a
              java.util.ConcurrentModificationException during undeployment
              which indicates a bug in WL - something is not getting
              synchronized that should be.
              As for MQ, their new extended client supports remote XA, which I think
              is the reason for the product in the first place. Even so, I
              still recommend testing to make sure that its messages
              participate in transactions. (Actually, I recommend such testing
              for any transactional app, including those built on WL JMS.)
              Tom
              Dmitri Maximovich wrote:
              > Hi Tom,
              >
              > Thanks for info, that's a relief. Unfortunately there is no hints in WLS
              > documentation that it's normal, that's why we were worried about it.
              >
              > Now there is one more issue, which I believe is related. You see with
              > those 'in-flight' transactions graceful shutdown of WLS doesn't quite
              > work. There is suspicious exception thrown and after that WLS is still
              > running in some state but console is not available anymore. Please see
              > console messages attached (sorry for long post). at the time of shutdown
              > there is no messages in the queue(s) so as far as I can tell those
              > 'pending transactions' mentioned is those from foreign JMS wrappers.
              >
              > I'd appreciate any comments on that. We have case opened with BEA about
              > this but so far they cannot reproduce it in their lab. That's why I
              > start wondering if we're doing something wrong here, like using remote
              > MQ server for example, may be you not supposed to (I remember there was
              > an issue before with IBM MQ that XA support required binding mode, I was
              > kind of hope that it's not the case anymore)?
              >
              > <Mar 3, 2004 1:47:56 PM EST> <Notice> <WebLogicServer> <BEA-000365>
              > <Server state changed to SUSPENDING>
              > <Mar 3, 2004 1:47:56 PM EST> <Info> <Deployer> <BEA-149236> <Preparing
              > to suspend.>
              > <Mar 3, 2004 1:47:56 PM EST> <Info> <Deployer> <BEA-149237> <Ready to
              > suspend.>
              > <Mar 3, 2004 1:47:56 PM EST> <Info> <WebService> <BEA-220028> <Web
              > Service reliable agents are suspended.>
              > <Mar 3, 2004 1:47:56 PM EST> <Notice> <JTA> <BEA-110476> <The server has
              > detected pending transactions during graceful shutdown. The server will
              > wait for the pending transactions to complete before suspending the RMI
              > service. A force shutdown command can be issued to shutdown the server
              > immediately.>
              > <Mar 3, 2004 1:48:26 PM EST> <Info> <Management> <BEA-141080> <A request
              > has been received to force shut down of the server.>
              > <Mar 3, 2004 1:48:26 PM EST> <Alert> <WebLogicServer> <BEA-000228> <The
              > disabling of server logins has been requested by <WLS Kernel>>
              > <Mar 3, 2004 1:48:26 PM EST> <Alert> <WebLogicServer> <BEA-000229>
              > <Server logins have been disabled.>
              > <Mar 3, 2004 1:48:26 PM EST> <Info> <WebService> <BEA-220028> <Web
              > Service reliable agents are suspended.>
              > <Mar 3, 2004 1:48:26 PM EST> <Info> <EJB> <BEA-010084> <The
              > message-driven beans are being suspended. This may take a minute or two.>
              > <Mar 3, 2004 1:48:32 PM EST> <Info> <EJB> <BEA-010085> <The
              > message-driven beans have all been suspended.>
              > <Mar 3, 2004 1:48:32 PM EST> <Info> <EJB> <BEA-010084> <The
              > message-driven beans are being suspended. This may take a minute or two.>
              > <Mar 3, 2004 1:48:32 PM EST> <Info> <EJB> <BEA-010085> <The
              > message-driven beans have all been suspended.>
              > [MessageDrivenBeanPoolInfoImpl] : Couldn't unregister MBean
              > javax.management.InstanceNotFoundException:
              > mydomain:ApplicationRuntime=myserver_otis-dasl-ejb,EJBComponentRuntime=myserver_otis-dasl-ejb_otis-dasl-ejb.jar,Location=myserver,Name=myserver_otis-dasl-ejb_otis-dasl-ejb.jar_com.cibcwm.go.otis.dasl.submission.DASLSubmissionMdb_wls.mqs.dasl.dev.adp.reply3,ServerRuntime=myserver,Type=EJBTransactionRuntime
              >
              > at
              > com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1680)
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1524)
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:947)
              >
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:908)
              >
              > at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
              > at
              > weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
              >
              > at
              > weblogic.management.runtime.EJBTransactionRuntimeMBean_Stub.preDeregister(EJBTransactionRuntimeMBean_Stub.java:433)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.internalDeleteMBean(MBeanHomeImpl.java:996)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.privateDeleteMBean(MBeanHomeImpl.java:982)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.access$000(MBeanHomeImpl.java:74)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl$2.run(MBeanHomeImpl.java:948)
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.management.internal.MBeanHomeImpl.deleteMBeanWithKernelID(MBeanHomeImpl.java:944)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.deleteMBean(MBeanHomeImpl.java:939)
              >
              > at
              > weblogic.management.internal.MBeanHomeImpl.deleteMBean(MBeanHomeImpl.java:933)
              >
              > at
              > weblogic.management.runtime.RuntimeMBeanDelegate.unregister(RuntimeMBeanDelegate.java:140)
              >
              > at
              > weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.unregisterDependents(EJBRuntimeMBeanImpl.java:58)
              >
              > at
              > weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.unregisterDependents(MessageDrivenEJBRuntimeMBeanImpl.java:50)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.unInitPool(MessageDrivenBeanPoolInfoImpl.java:208)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.onUndeploy(MessageDrivenBeanPoolInfoImpl.java:121)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.onUndeploy(MessageDrivenBeanInfoImpl.java:628)
              >
              > at weblogic.ejb20.internal.BaseEJBHome.undeploy(BaseEJBHome.java:203)
              > at
              > weblogic.ejb20.internal.MessageDrivenEJBHome.undeploy(MessageDrivenEJBHome.java:260)
              >
              > at
              > weblogic.ejb20.deployer.EJBDeployer.deactivate(EJBDeployer.java:1802)
              > at weblogic.ejb20.deployer.EJBModule.doDeactivate(EJBModule.java:865)
              > at weblogic.ejb20.deployer.EJBModule.deactivate(EJBModule.java:712)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivateModule(J2EEApplicationContainer.java:3161)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2186)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2131)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.stop(J2EEApplicationContainer.java:1915)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:761)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.prepareToSuspend(ApplicationService.java:46)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.prepareToSuspend(SubsystemManager.java:168)
              >
              > at weblogic.t3.srvr.T3Srvr.prepareToSuspend(T3Srvr.java:1085)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.prepareToSuspend(ServerLifeCycleWorkerThread.java:51)
              >
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread$1.run(ServerLifeCycleWorkerThread.java:35)
              >
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.run(ServerLifeCycleWorkerThread.java:32)
              >
              > --------------- nested within: ------------------
              > weblogic.management.ManagementException: An error has occurred during
              > preDeregister().
              > nullmydomain:ApplicationRuntime=myserver_otis-dasl-ejb,EJBComponentRuntime=myserver_otis-dasl-ejb_otis-dasl-ejb.jar,Location=myserver,Name=myserver_otis-dasl-ejb_otis-dasl-ejb.jar_com.cibcwm.go.otis.dasl.submission.DASLSubmissionMdb_wls.mqs.dasl.dev.adp.reply3,ServerRuntime=myserver,Type=EJBTransactionRuntime
              > - with nested exception:
              > [javax.management.InstanceNotFoundException:
              > mydomain:ApplicationRuntime=myserver_otis-dasl-ejb,EJBComponentRuntime=myserver_otis-dasl-ejb_otis-dasl-ejb.jar,Location=myserver,Name=myserver_otis-dasl-ejb_otis-dasl-ejb.jar_com.cibcwm.go.otis.dasl.submission.DASLSubmissionMdb_wls.mqs.dasl.dev.adp.reply3,ServerRuntime=myserver,Type=EJBTransactionRuntime]
              >
              > at
              > weblogic.management.runtime.RuntimeMBeanDelegate.unregister(RuntimeMBeanDelegate.java:148)
              >
              > at
              > weblogic.ejb20.monitoring.EJBRuntimeMBeanImpl.unregisterDependents(EJBRuntimeMBeanImpl.java:58)
              >
              > at
              > weblogic.ejb20.monitoring.MessageDrivenEJBRuntimeMBeanImpl.unregisterDependents(MessageDrivenEJBRuntimeMBeanImpl.java:50)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.unInitPool(MessageDrivenBeanPoolInfoImpl.java:208)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanPoolInfoImpl.onUndeploy(MessageDrivenBeanPoolInfoImpl.java:121)
              >
              > at
              > weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.onUndeploy(MessageDrivenBeanInfoImpl.java:628)
              >
              > at weblogic.ejb20.internal.BaseEJBHome.undeploy(BaseEJBHome.java:203)
              > at
              > weblogic.ejb20.internal.MessageDrivenEJBHome.undeploy(MessageDrivenEJBHome.java:260)
              >
              > at
              > weblogic.ejb20.deployer.EJBDeployer.deactivate(EJBDeployer.java:1802)
              > at weblogic.ejb20.deployer.EJBModule.doDeactivate(EJBModule.java:865)
              > at weblogic.ejb20.deployer.EJBModule.deactivate(EJBModule.java:712)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivateModule(J2EEApplicationContainer.java:3161)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2186)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2131)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.stop(J2EEApplicationContainer.java:1915)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:761)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.prepareToSuspend(ApplicationService.java:46)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.prepareToSuspend(SubsystemManager.java:168)
              >
              > at weblogic.t3.srvr.T3Srvr.prepareToSuspend(T3Srvr.java:1085)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.prepareToSuspend(ServerLifeCycleWorkerThread.java:51)
              >
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread$1.run(ServerLifeCycleWorkerThread.java:35)
              >
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.run(ServerLifeCycleWorkerThread.java:32)
              >
              > <Mar 3, 2004 1:48:33 PM EST> <Info> <Management> <BEA-141082>
              > <ServerRuntime:java.util.ConcurrentModificationException>
              > <Mar 3, 2004 1:48:33 PM EST> <Info> <Management> <BEA-141082>
              > <ServerRuntime:java.util.ConcurrentModificationException
              > at
              > java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:552)
              > at java.util.LinkedList$ListItr.next(LinkedList.java:488)
              > at
              > weblogic.ejb20.deployer.EJBDeployer.deactivate(EJBDeployer.java:1801)
              > at weblogic.ejb20.deployer.EJBModule.doDeactivate(EJBModule.java:865)
              > at weblogic.ejb20.deployer.EJBModule.deactivate(EJBModule.java:712)
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivateModule(J2EEApplicationContainer.java:3161)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2186)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.deactivate(J2EEApplicationContainer.java:2131)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainer.stop(J2EEApplicationContainer.java:1915)
              >
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:761)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.prepareToSuspend(ApplicationService.java:46)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.prepareToSuspend(SubsystemManager.java:168)
              >
              > at weblogic.t3.srvr.T3Srvr.prepareToSuspend(T3Srvr.java:1085)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.prepareToSuspend(ServerLifeCycleWorkerThread.java:51)
              >
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread$1.run(ServerLifeCycleWorkerThread.java:35)
              >
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at
              > weblogic.t3.srvr.ServerLifeCycleWorkerThread.run(ServerLifeCycleWorkerThread.java:32)
              >
              > >
              > <Mar 3, 2004 1:48:35 PM EST> <Critical> <WebLogicServer> <BEA-000217>
              > <Failed to fully suspend the server due to:
              > java.util.ConcurrentModificationException
              > java.util.ConcurrentModificationException
              > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
              > at java.util.HashMap$KeyIterator.next(HashMap.java:818)
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:751)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.forceSuspend(ApplicationService.java:82)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.forceSuspend(SubsystemManager.java:184)
              > at weblogic.t3.srvr.T3Srvr.forceSuspend(T3Srvr.java:1097)
              > at
              > weblogic.t3.srvr.ServerRuntime.uprotectedForceShutdown(ServerRuntime.java:629)
              >
              > at weblogic.t3.srvr.ServerRuntime.access$300(ServerRuntime.java:83)
              > at weblogic.t3.srvr.ServerRuntime$4.run(ServerRuntime.java:563)
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at weblogic.t3.srvr.ServerRuntime.forceShutdown(ServerRuntime.java:559)
              > at weblogic.t3.srvr.ServerRuntime.shutdown(ServerRuntime.java:547)
              > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              > at
              > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              >
              > at
              > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              >
              > at java.lang.reflect.Method.invoke(Method.java:324)
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:711)
              >
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:690)
              >
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:947)
              >
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:908)
              >
              > at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
              > at
              > weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
              >
              > at
              > weblogic.management.runtime.ServerRuntimeMBean_Stub.shutdown(ServerRuntimeMBean_Stub.java:1184)
              >
              > at
              > weblogic.server.ServerLifeCycleRuntime$ShutdownRequest.execute(ServerLifeCycleRuntime.java:585)
              >
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              > >
              > <Mar 3, 2004 1:48:35 PM EST> <Debug> <Management> <BEA-141132> <Dynamic
              > invocation while executing action shutdown on
              > mydomain:Location=myserver,Name=myserver,Type=ServerRuntime MBean
              > instance failed. The method shutdown with signature [int, boolean] was
              > invoked with parameters as [30, true].
              > java.util.ConcurrentModificationException
              > at java.util.HashMap$HashIterator.nextEntry(HashMap.java:782)
              > at java.util.HashMap$KeyIterator.next(HashMap.java:818)
              > at
              > weblogic.j2ee.J2EEApplicationContainerFactory.removeDeployedApplications(J2EEApplicationContainerFactory.java:751)
              >
              > at
              > weblogic.j2ee.J2EEApplicationService.shutdown(J2EEApplicationService.java:115)
              >
              > at
              > weblogic.management.deploy.DeploymentManagerServerLifeCycleImpl.shutdownHelper(DeploymentManagerServerLifeCycleImpl.java:257)
              >
              > at
              > weblogic.application.ApplicationService.forceSuspend(ApplicationService.java:82)
              >
              > at
              > weblogic.t3.srvr.SubsystemManager.forceSuspend(SubsystemManager.java:184)
              > at weblogic.t3.srvr.T3Srvr.forceSuspend(T3Srvr.java:1097)
              > at
              > weblogic.t3.srvr.ServerRuntime.uprotectedForceShutdown(ServerRuntime.java:629)
              >
              > at weblogic.t3.srvr.ServerRuntime.access$300(ServerRuntime.java:83)
              > at weblogic.t3.srvr.ServerRuntime$4.run(ServerRuntime.java:563)
              > at
              > weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
              >
              > at
              > weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
              > at weblogic.t3.srvr.ServerRuntime.forceShutdown(ServerRuntime.java:559)
              > at weblogic.t3.srvr.ServerRuntime.shutdown(ServerRuntime.java:547)
              > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
              > at
              > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
              >
              > at
              > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
              >
              > at java.lang.reflect.Method.invoke(Method.java:324)
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:711)
              >
              > at
              > weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:690)
              >
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
              > at
              > com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.private_invoke(RemoteMBeanServerImpl.java:947)
              >
              > at
              > weblogic.management.internal.RemoteMBeanServerImpl.invoke(RemoteMBeanServerImpl.java:908)
              >
              > at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:946)
              > at
              > weblogic.management.internal.MBeanProxy.invokeForCachingStub(MBeanProxy.java:481)
              >
              > at
              > weblogic.management.runtime.ServerRuntimeMBean_Stub.shutdown(ServerRuntimeMBean_Stub.java:1184)
              >
              > at
              > weblogic.server.ServerLifeCycleRuntime$ShutdownRequest.execute(ServerLifeCycleRuntime.java:585)
              >
              > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
              > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
              > >
              >
              > Tom Barnes wrote:
              >
              >> Hi Dmitri,
              >>
              >> This is normal behavior.
              >> The internal rollbacks are a side effect of WL MDBs
              >> necessarily starting a transaction before they (internally)
              >> post a synchronous
              >> receive on the remote foreign JMS server. If the synchronous receive
              >> receives nothing, the tx is rolled back, and another
              >> synch receive is posted with a new tx. (When interacting with
              >> foreign vendors, tx MDBs usually must post synchronous receives
              >> in order to infect the received message - there is no
              >> standard JMS API for infecting asynchronously received messages
              >> with a user transaction.)
              >>
              >> Tom
              >>
              >> Dmitri Maximovich wrote:
              >>
              >>> Hi everybody,
              >>>
              >>> Is anybody successfully using remote IBM MQseries 5.3 server as
              >>> Foreign JMS in WLS 8.1sp2?
              >>> We're observing some strange behavior in this case. Here is our setup:
              >>>
              >>> WLS and IBM MQ server deployed on separate boxes.
              >>> WLS version 8.1sp2 running on Windows 2000/Intel
              >>> IBM MQ version 5.3 running on Solaris/SPARC
              >>>
              >>> We're using "WebSphere MQ classes for Java, version 5.303 -
              >>> j5303-L030225"
              >>> and "WebSphere MQ Extended Transactional Client Feature, version
              >>> 5.300 - j5303-L030122"
              >>>
              >>> MQ files added in WLS POST_CLASSPATH variable in WLS starup script.
              >>>
              >>> Foreign JMS server configured in WLS via fscontext JNDI.
              >>>
              >>> MDB bean deployed with Transaction attribute "Required".
              >>>
              >>> Everything seems to work fine, if we're posting message to MQ queue
              >>> MDB receives it and process successfully (just print message content
              >>> to the console for now).
              >>>
              >>> Problem: In WLS console, under Server->Monitoring->JTA->Monitor
              >>> inflight transactions we can constantly see one transaction enlisted
              >>> for our MDB bean with following details:
              >>>
              >>> =====================================================
              >>> Transaction ID: BEA1-00DFC5EB4B7B7F28EDB9
              >>> Coordinator: mydomain+myserver
              >>> Name: JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              >>> Status: Active
              >>> Seconds Active: 17
              >>> Resources:
              >>> weblogic.ejb20.JMSConnectionPoller.xxx.xxx.MyMessageProcessorMdb=started
              >>> Properties
              >>> (key=value):
              >>> weblogic.transaction.name=JMSMessagePoller.xxx.xxx.MyMessageProcessorMdb
              >>> =====================================================
              >>>
              >>> This transaction seems to be Active for 30 seconds and then rolled
              >>> back (no error messages on WLS console displayed).On JTA statistics
              >>> page in WLS console "Total Rolled Back" counter keeps increneting
              >>> with every rollback.
              >>>
              >>> Does anybody observerd similar problem? May be it's normal behaviour
              >>> but I'm kind of worrying about those transactions and constant
              >>> rollback. I'd appreciate any feedback.
              >>>
              >>> ---
              >>> Sincerely,
              >>> Dmitri Maximovich
              >>
              >>
              >>
              

  • JDBC, JMS and EJB transactions - possible problem?

    Hello,
              I am using Oracle 9, Weblogic 8.1 SP 4, MyEclipse and
              XDoclet.
              In my current project I have the following piece of code
              in one of my message driven beans (code cited as pseudocode
              without unnecessary details):
              * @ejb.bean name="MyMessageProcessor"
              * display-name="Display name for a MyMessageProcessor"
              * jndi-name="ejb/MyMessageProcessor"
              * description="Bean MyMessageProcessor"
              * destination-type="javax.jms.Queue"
              * transaction-type="Container"
              * acknowledge-mode="Auto-acknowledge"
              * subscription-durability="Durable"
              * generate="false"
              * @ejb.transaction type="Required"
              public class MyMessageProcessor implements MessageDrivenBean, MessageListener {
              public void onMessage(Message msg) {
                   try {
                        //obtaining connections to two different databases via JNDi
                        java.sql.Connection connOne =
                        ((DataSource)ctx.lookup("DataSourceOne")).getConnection();          
                        java.sql.Connection connTwo =
                             ((DataSource)ctx.lookup("DataSourceTwo")).getConnection();
                        // performing some UPDATEs and INSERTs on connOne and connTwo
                        // calling some other methods of this bean
                        //creating the reply JMS message and sending it to another JMS queue
                        Message msgTwo = this.createReplyMessage(msg)
                        this.queueSender.send(msgTwo);
                        //commiting everything
                        this.queueSession.commit();          
                   } catch (Exception ex) {
                   try {
                        if (this.queueSession!=null) this.queueSession.rollback();
                   } catch (JMSException JMSEx) {};     
                   this.context.setRollbackOnly();
              Some days ago (before the final remarks from my client) there used to be only one DataSource configurated on the basis of the
              connection pool with non-XA jdbc driver. Everything worked fine
              including the transactions (if anything wrong happend not only wasn't the replymessage sent, but also no changes were written
              to database and the incomming message was thrown back to the my bean's
              queue).
              When I deployed the second DataSource I was informed by an error message, that only one non-transactional resource may
              participate in a global transaction. When I changed both datasources
              to depend on underlying datasources with transatcional (XA) jdbc drivers, everything stopped working. Even if
              EJB transaction was theoretically successfully rolledbacked, the changed were written to the database
              and the JMS message wasn't resent to the JMS queue.
              So here are my questions:
                   1. How to configure connection pools to work in such situations? What JDBC drivers should I choose?
                   Are there any global server configurations, which may influence this situation?
                   2. Which jdbc drivers should I choose so that the container was able to rollback the database transactions
                   (of course, if necessary)?
                   3. Are there any JMS Queue settings, which would disable the container to send message back to the
                   queue in case of setRollbackOnly()? How should be the Queue configurated?
              As I am new to the topic and the deadline for the project seems to be too close I would be grateful
              for any help.
              This message was sent to EJB list and JDBC list.
              Sincerely yours,
              Marcin Zakidalski

    Hi,
              I found these information extremely useful and helpful.
              The seperate transaction for sending messages was, of course, unintentional. Thanks a lot.
              Anyway, I still have some problems. I have made some changes to the
              code cited in my previous mail. These changes included changing QueueSessions
              to non-transactional. I also set the "Honorate global transactions" to true.
              I am using XA JDBC driver. After setting "Enable local transactions" to false
              (I did it, because I assume that JDBC transactions should be part on the global
              EJB transaction) I got the following error:
              java.sql.SQLException: 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() or Connection.rollback().
              I have also inspected the calls of methods of bean inside of onMessage() method just to check, whether
              the transactions are correctly initialized (using the weblogic.transaction.Transaction class).
              My questions are as follows:
              1. Any suggestions how to solve it? I have gone through the google answers on that problem and only
              thing I managed to realize that JDBC must start its own transaction. Is there any way to prohibit it
              from doing that? Can using setAutocommit(true/false) change the situation for better?
              2. How to encourage the JDBC driver to be a part of EJB transaction?
              3. As I have noticed each of ejb method has its own transactions (transactions have different
              Xid). Each method of the bean has "required" transaction attribute. Shouldn't it work in such
              way that if already started transaction exists it is used by the called method?
              4. The DataSources are obtained in my application via JNDI and in the destination environment I will have slight
              impact on the configuration of WebLogic. What is least problematic and most common WebLogic configuration which would
              enable JDBC driver to participate in the EJB transaction? Is it the WebLogic configuration problem or can it be
              solved programmically?
              Currently my module works quite fine when "enable local transactions" for DataSources is set to true, but this way
              I am loosing the ability to perform all actions in one transaction.
              Any suggestions / hints are more than welcomed. This message was posted to jdbc list and ejb list.
              Marcin

  • JMS and XA Transaction

              Hy,
              I see that the JMS is integrated as XA Transaction directly from the container management
              on the Weblogic version 7.0.
              I test the same testcase on the Weblogic 6.0 but it didn't work automatically (the
              publish never commit).
              Starting from wich version of Weblogic the JMS-XA Transaction is integrated ?
              Thank you.
              Luigi
              

              Hy,
              I see that the JMS is integrated as XA Transaction directly from the container management
              on the Weblogic version 7.0.
              I test the same testcase on the Weblogic 6.0 but it didn't work automatically (the
              publish never commit).
              Starting from wich version of Weblogic the JMS-XA Transaction is integrated ?
              Thank you.
              Luigi
              

  • JMS and JDBC Transaction

    I have recently tried using the JMS interface for AQ and I have discovered that the queue connection is a separate JDBC connection even if you create a queue connection using an OracleConnection. Is there a workaround for this? It seems a bit strange to have two connections open to the database and be forced to use an XA session in order to get the commits synchronized. Any ideas ? Below is some sample code I am using:
    queueConnection = AQjmsQueueConnectionFactory.createQueueConnection((OracleConnection)connection);
    queueConnection.start();
    QueueSession queueSession = queueConnection.createQueueSession(true, Session.CLIENT_ACKNOWLEDGE);
    AQjmsSession aqs = (AQjmsSession)queueSession;
    Queue queue = aqs.getQueue("TEST_SCHEMA", "TEST_QUEUE");

    Hello,
    What version are you using of the jar files? What version of the database are you using?
    From what I recall the example in <Note:301434.1> successfully reused an existing JDBC connection.
    I would be interested to see a more complete code example if this is not helpful.
    Thanks
    Peter

  • Foreign JMS server connection issue.

    Hi All,
    We are migrating a JMS application from websphere 6.1 to weblogic 10.3. The message queue resides in a TIBCO EMS server.
    We are trying to configure the foreign JMS server through JMS Module in the admin console. We are getting the following error will deploying the application.
    +<May 4, 2009 12:32:52 AM PDT> <Warning> <EJB> <BEA-010061> <The Message-Driven EJB: TxnMessageSubscriber is unable to connect to the JMS destination: weblogic.bbmdb-txn.jms/system+
    module-0-jms.xml. The Error was:
    Can not get distribute destination information. The destination JNDI name is weblogic.bbmdb-txn.jms/systemmodule-0-jms.xml, the provider URL is null>
    we have provided the connection URL in "JNDI Connection URL" column in the foreign server setup page.
    Is there any other thing that need to be configured?

    I m facing the same problem, we are using Weblogic Server 10.3.
    We have defined a cluster on one Weblogic server and have created one managed server in the cluster machine and the other managed server in another machine.
    We are using Foreign JMS and I m getting the error as follow:
    ####<Jun 19, 2009 3:30:53 PM IST> <Warning> <EJB> <iflexpkw513> <Managed1> <[STANDBY] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1245405653881> <BEA-010061> <The Message-Driven EJB: TestJMSALSB is unable to connect to the JMS destination: fcssi/FCSSI. The Error was:
    Can not get distribute destination information. The destination JNDI name is fcssi/FCSSI, the provider URL is null>
    Not able to understand what is the problem here...
    ejb-jar.xml :
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd">
    <ejb-jar id="ejb-jar_ID">
    <enterprise-beans>
    <message-driven>
    <ejb-name>TestJMSALSB</ejb-name>
    <ejb-class>samplemdb.TestJMSALSB</ejb-class>
    <transaction-type>Container</transaction-type>
    <message-driven-destination id="MessageDrivenDestination_1169302343246">
         <destination-type>javax.jms.Queue</destination-type>
    </message-driven-destination>
    </message-driven>
    </enterprise-beans>
    </ejb-jar>
    weblogic-ejb-jar.xml :
    <?xml version="1.0" encoding="UTF-8"?>
    <weblogic-ejb-jar
    xmlns="http://www.bea.com/ns/weblogic/90" xmlns:j2ee="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd">
    <weblogic-enterprise-bean>
    <ejb-name>TestJMSALSB</ejb-name>
    <message-driven-descriptor>
    <destination-jndi-name>fcssi/FCSSI</destination-jndi-name>
    <connection-factory-jndi-name>iflex/fcssiQCF</connection-factory-jndi-name>
    </message-driven-descriptor>
    </weblogic-enterprise-bean>
    </weblogic-ejb-jar>
    Can anyone provide some help on this.....

  • Foreign JMS Server Persistance\Retry in case Remote JMS Provider goes down

    Hi All
    I would need more clarity on this. How does the Foreign JMS Server behave in case the remote JMS provider goes down. Does it take the message from the Publishing Proxy Service and retries\persists the JMS Message till the remote provide is up?
    Please let us know. This would effect our design as retrial is very important here. Thanks

    If you want to provide guaranteed delivery with automatic retries when using remote JMS implementations, there are multiple ways to implement it:
    1. While reading from a foreign JMS destination
    Create a Foreign JMS server using transactional drivers (use XA in case of JMS). The messages remain on remote server JMS queue and OSB proxy polls the message directly on remote server. So if Remote Server is down OSB will not be able to read the message. Once remote server is up OSB will pick up the message (as long as foreign JMS server provides persistence and maintains the messages in the queue during a server restart). In case of error in OSB foreign queue can do retry if it provides a retry mechanism.
    2. While writing the message to a foreign JMS destination
    a. Use a foreign JMS server using transactional connection. Put the retry mechanism in OSB Business service which writes to the foreign JMS/MQ queue. In case of failure Business Service can retry based on configuration. If you want to provide guaranteed delivery then create a local JMS queue to store the messages. So when remote destination is down for a long time undelivered messages will be rolled back to the local queue. You can put retry mechanism on the local queue.
    b. Use a messaging bridge which will write the messages to the remote destination. You can configure retry delivery rules in messaging bridge so once busienss service writes the message to the bridge, a SAF agent will ensure the delivery to remote destination whenever it is up.

  • Weblogic: problem with JMS foreign server and Transaction

    Hello everyone,
    I am working with an enterprise application with Web Application Server Logic 10.3. L 'application uses the following components:
    1) MDB 2.0
    2) FOREIGN JMS SERVER -> WebSpereMQ
    3) EJB SESSION
    L 'MDB calls the session bean which uses in its ejb-jar.xml using a Wrapper for JMS QueueConnectionFactory with res-ref:
    <resource- ref>
    <res-ref-name> jms / iss / QCFIXP </ res-ref-name>
    <res-auth> Container </ res-auth>
    <res-sharing -scope> Shareable </ res-sharing-scope>
    <resource- ref>
    The MDB is CMT
    <transaction-type> Container </ transaction-type>
    while the session bean is BMT
    <transaction-type> Bean </ transaction-type>
    to call the QCFIXP in its transaction.
    The QCFIXP ii an XA resource
    When there is a rollback operation in SessionBean also in 'MDB
    There 'an operation setRollbackOnly:
    getMessageDrivenContext (). setRollbackOnly ();
    After this operation on the MDB I do a JNDI look up the QueueConnectionFactory but sending the message on a queue I get the following exception:
    javax.jms.JMSException: [JMSPool: 169809] An error occurred while registering the JMS connection with JTA:
    But if not using the "wrapper jms" in the session bean I did not take any exception and the application don' t have any error.
    My doubt is :
    Why if I use the JMS wrapper I get an error javax.jms.JMSException: [JMSPool: 169809] An error occurred while registering the JMS connection with JTA?
    Thanks in advance.
    Michele
    Edited by: user3501731 on 11-mag-2011 3.16

    Hi Tom,
    Thanks very much for your responses and careful analysis you've done.
    Following the source code of the MDB where error occurs.
    Marked In bold the line where the exception is thrown.
         public void onMessage(Message msg) {
    //          Utility.logger(AP.DEBUG, "Partito MDB 2");
              processa(msg);
              protected void processa(Message msg) {
              Utility.logger(
                   AP.DEBUG,
                   "IXPReceiverMDB7.processa(Message msg) partito");
              try {
                   long start = System.currentTimeMillis();
    /*               Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB.processa(Message msg) effettuo lookup");*/
                   ejb = myEjbLocalHome.create();
                   // individuo l'identificativo del messaggio in ricezione
                   String msgid = msg.getJMSMessageID();
                   Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB7.processa(Message msg) elaboro messaggio:"
                             + msgid);
                   String charset = msg.getStringProperty("JMS_IBM_Character_Set");
                   Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB7.processa Charset:" + charset );
                   // invoco il processo di ricezione
                   boolean commitRequested = ejb.processa(ctlReq, encoding, msg);
                   // il valore di ritorno del processo di ricezione identifica o meno
                   // la necessita' di effettuare il rollback dell'intero processo
                   if (!commitRequested) {
                        getMessageDrivenContext().setRollbackOnly();
                   if (ctlReq) {
                        Utility.logger(
                             AP.INFO,
                             "IXPReceiverMDB7.processa(Message msg) spedisco il messaggio pilota del 'cleaning' con JMSCorrelationID = '"
                                  + msgid
                                  + "'");
                        msg.setJMSCorrelationID(msgid);
                        // Viene creata la QueueConnection
                        QueueConnectionFactory factory =
                             JmsFactoryDispenser.getSingleton().getFactory();
                        QueueConnection connection = factory.createQueueConnection();
                        // Viene ottenuta la 'session'
                        QueueSession session =
                             connection.createQueueSession(
                                  false,
                                  Session.AUTO_ACKNOWLEDGE);
                        // spedisco il messaggio sulla coda abbinata al processo di 'cleaning'
                        // della coda di controllo
                        IXPMessageManager msgManager = new IXPMessageManager(session);
                        msgManager.spedisci(msg, AP.PILOTQUEUE, "J", AP.STD_MESSAGE);                    session.close();
                        connection.close();
                   long end = System.currentTimeMillis();
                   Long durata = new Long (end - start);
                   Utility.logger(
                        AP.INFO,
                        "IXPReceiverMDB7 Tempo totale elaborazione messaggio: " +
                        msgid + " " +
                        durata.toString() + " mill" );
                   Utility.logger(
                        AP.DEBUG,
                        "IXPReceiverMDB7.processa(Message msg) terminato");
              } catch (Throwable e) {
                   getMessageDrivenContext().setRollbackOnly();
                   try {
                        Utility.myExceptionHandler(
                             "E",
                             "1",
                             "4028",
                             "IXPReceiverMDB.onMessage()",
                             e);
                   } catch (Throwable ex) {
                        ex.printStackTrace();
    Thanks in advance.
    Edited by: serpichetto on 16-mag-2011 1.24

  • JMS and transactions

    Dear all,
    I need some clarification about JMS for my Thesis : after reading some tutorials I still am confused about JMS used with JTA transactions.
    1) If a JMS transacted session is started within a JTA transaction (let's say a UserTransaction spanned by an EJB) and the transaction rolls back, the message will be put back in the Queue, right ?
    2) Is it true also the opposite ? that is if I perform some insert/delete/update within a JMS transacted session, and the transaction is rolled back, the insert/delete/update are rolled back too ?
    Thank you very much for your help
    Lucas

    Hi Lucas,
    What you describe requires XA or distributed transactions. And (I'm fairly sure) XA doesn't work with Bean Managed Transactions and the UserTransaction interface. XA allows multiple transactional resources to get enlisted in a global transaction. When the app server decides all the work is done, the global transaction is committed or rolled back using a two-phase commit protocol.
    So except for the UserTransaction bit, what you describe is how it works. The messages will be only sent/received and the database work will only be committed if the whole global transaction is committed. If any part is rolled back, everything will be rolled back. JMS implementations typically will set the JMSRedelivered flag along with incrementing the JMSXDeliveryCount property when messages are put back on the destination.
    Dwayne
    =========================
    [http://dropboxmq.sourceforge.net/]

  • Load balancing MQ 7.0 Foreign JMS Server and Weblogic 10 MDBs?

    We have the following configuration and we are trying to troubleshoot what appears to be a load balancing issue.
    We have 3 Solaris servers. Each Solaris server has two Weblogic managed servers running on it. There are a total of 6 managed servers in the Weblogic cluster.
    MQ Series 7.0 is also installed on each Solaris server. The MQ queue managers are in a MQ cluster. Each queue manager has the same queues defined.
    We have a foreign JMS Server configured on Weblogic that has destinations and a connection factory defined. There aren't many configuration options available for the connection factory. The destinations are bound to the queues defined on MQ using the MQ bindings file.
    The MQ bindings file was generated using the TRANSPORT(BIND) mechanism. Each bindings file points to the queue manager running on that machine. So the 2 managed servers running on one machine are accepting messages from the queue manager on that machine.
    The MDB's listenning for messages on the MQ queues are configured as follows in the weblogic-ejb-jar.xml:
         <max-beans-in-free-pool>16</max-beans-in-free-pool>
    We also created a custom work manager with min threads constraint=5 and max threads constraint=16. The dispatch-policy of all the MDBs is set to the custom work manager.
    The open input count on each MQ queue managers shows up as 32 which is expected.
    The default load algorithm on the cluster is round-robin.
    When we run a load test (injecting 40 messages per second on one MQ queue), we notice that one managed server ends up being significantly loaded than the other. Each MQ queue manager in the MQ cluster receives approximately the same number of messages in the load test. But it seems like one managed server is preferred over the other in Weblogic.
    What can be done to equally balance the load among the two managed servers on each Solaris server?
    Thanks for the help.

    Load balancing generally applies at determing how many consumer threads has to be created on each of the clustered queue instance. In that sense you have achieved perfect load balancing as your queue instances has the same no of consumer threads.
    Once you have set 'x' consumer threads on a queue, it is upto messaging provider to decide which thread to deliver a particular message and you will hardly have any control over this. Since your 32 threads are listening on the same queue, MQ can select any thread for delivering the message and the behaviour could be non deterministic.
    One option to change your design is to have a dispacther mdb which picks the messages off the MQ and then routes to a weblogic distributed destination and you can have your core mdb which does all processing listen to this distributed destination. You can enable load balancing when the disaptcher mdb routes the message to the distributed destination. Since dispatcher MDB is nothing more than a router, the unbalanced consumption off the MQ shouldn't seriously affect the server.

  • Foreign JMS QCF and Weblogic Sever Session Pool

              Hi!
              We have Weblogic 6.1 SP2 installation.
              We are trying to use JMS Server session pool and connection consumer configuration
              with MQSeries QCF registered to weblogic JNDI via startup class.
              Upon server startup weblogic is throwing ClassCast exception for QueueConnection.
              It seems weblogic is expecting QueueConnection implementation by weblogic.
              Any suggestions or alternative way of doing it.
              Thanks
              Jay PArikh
              

    Hi Jay,
              Server session pools do not support foreign providers.
              The preferred way to integrate foreign providers is via MDBs or
              via the Messaging Bridge (bridge available in SP3). For a
              comprehensive write-up on integrating foreign providers with
              WL see the whitepaper "Using Foreign JMS Providers with
              WebLogic Server" on dev2dev.bea.com.
              Tom
              Jay Parikh wrote:
              > Hi!
              >
              > We have Weblogic 6.1 SP2 installation.
              >
              > We are trying to use JMS Server session pool and connection consumer configuration
              > with MQSeries QCF registered to weblogic JNDI via startup class.
              >
              > Upon server startup weblogic is throwing ClassCast exception for QueueConnection.
              > It seems weblogic is expecting QueueConnection implementation by weblogic.
              >
              > Any suggestions or alternative way of doing it.
              >
              > Thanks
              > Jay PArikh
              

  • Foreign jms connection factory username and password

    I have to connect to TIBCO as the foreign JMS. I have created a foreign JMS server and configured JNDI properties including username and password. I configured a connection factory and specified username and password as well. Finally, I configured foreign destination.
              In web.xml and corresponding welogic.xml, I am using the resource-ref with Container authentication.
              With the above, I always get the following exception.
              javax.jms.JMSSecurityException: Not permitted
                   at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:499)
                   at com.tibco.tibjms.TibjmsSession._createProducer(TibjmsSession.java:697)
                   at com.tibco.tibjms.TibjmsQueueSession.createSender(TibjmsQueueSession.java:123)
              The above code works fine under the following circumstances:
              * If I don't use any username and passwords.
              * If I pass the username and password to the connection factory when creating the connection. According to the documentation here (http://e-docs.bea.com/wls/docs81/jms/j2ee_components.html#1033768) doing so in an error:(
              Any ideas or suggestions?

    Even though I had configured things in the web.xml and weblogic.xml, I didn't use them. So, instead of using global JNDI, I used java:comp/env JNDI. Once, I used the correct JNDI, the connection is working... I will continue to do further testing.
              > I have to connect to TIBCO as the foreign JMS. I
              > have created a foreign JMS server and configured JNDI
              > properties including username and password. I
              > configured a connection factory and specified
              > username and password as well. Finally, I configured
              > foreign destination.
              >
              > In web.xml and corresponding welogic.xml, I am using
              > the resource-ref with Container authentication.
              >
              > With the above, I always get the following exception.
              >
              >
              > javax.jms.JMSSecurityException: Not permitted
              > at
              > t
              > com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:4
              > 99)
              > at
              > t
              > com.tibco.tibjms.TibjmsSession._createProducer(TibjmsS
              > ession.java:697)
              > at
              > t
              > com.tibco.tibjms.TibjmsQueueSession.createSender(Tibjm
              > sQueueSession.java:123)
              >
              > The above code works fine under the following
              > circumstances:
              > * If I don't use any username and passwords.
              > * If I pass the username and password to the
              > connection factory when creating the connection.
              > According to the documentation here
              > e
              > (http://e-docs.bea.com/wls/docs81/jms/j2ee_components.
              > html#1033768) doing so in an error:(
              >
              > Any ideas or suggestions?

  • Foreign JMS between 8.1 and 7.0

              We are experience strange behaviour when we are using foreign JMS between 8.1 and
              7.0. When one MDB on a 8.1 server connects to the JMS on the 7.0 server everything
              is fine. When a second 8.1 server connect to a JMS queue on the 7.0 server the
              it seems to connect but the messages on hanging as pending. If we writes the provider
              URL directly into the MDB descriptor it seems to work. Should foreign JMS work
              between WLS versions? Is there any way to get more debugging information?
              Björn Caroll
              

    It should work. All a "Foreign JMS Provider" is in 8.1 is a way to create
              sort of a "symbolic link" in JNDI between some objects in another JNDI
              provider and the local WLS JNDI tree.
              You can get more info out of the MDB startup process by setting the
              following command-line settings when you start weblogic.Server:
              -Dweblogic.ejb.jms.connect.debug=true
              -Dweblogic.ejb.jms.connect.verbose=true
              (You'll also have to have "StdoutDebugEnabled" set in the "Server" element
              of your config.xml file, or you'll have to turn on that checkbox in the
              console.)
              Also, if you post your MDB deployment descriptors and the ForeignJMS stuff
              from config.xml, we might have some ideas.
              greg
              "Björn Caroll" <[email protected]> wrote in message
              news:3fd6f281$[email protected]..
              >
              > We are experience strange behaviour when we are using foreign JMS between
              8.1 and
              > 7.0. When one MDB on a 8.1 server connects to the JMS on the 7.0 server
              everything
              > is fine. When a second 8.1 server connect to a JMS queue on the 7.0 server
              the
              > it seems to connect but the messages on hanging as pending. If we writes
              the provider
              > URL directly into the MDB descriptor it seems to work. Should foreign JMS
              work
              > between WLS versions? Is there any way to get more debugging information?
              >
              > Björn Caroll
              

  • Foreign JMS Providers with WebLogic Server does not close connection

              Hello All,
              We tried to use wlsmqseries.zip classes (specially JNDI Mapper) for integrating
              WebLogic Server with MQ so that we can incorporate XA transactions. We use LDAP
              context factory to bind MQ.
              We found a number of LDAP connections are getting opened by JNDIMapper, but it's
              not getting closed.
              Can some one give some clue to this ?
              Also any suggestion to serve the current purpose is welcome.
              Thanks,
              Sudarson
              

    What version are you using? "wlsmqseries.zip" does enlisting of MQ JMS
              sessions in XA transactions, but WLS 8.1 does that for you out of the box.
              If you're using 8.1, it would be better to use the new 8.1 features for
              foreign JMS providers.
              A place to start is the "Using WebLogic JMS with EJBs and Servlets" section
              of the JMS programming documentation for 8.1, and there have been many other
              posts on this newsgroup with details. (There also appear to be quite a few
              customers using this feature in their own systems, judging from the number
              of posts.)
              greg
              "sudarson" <[email protected]> wrote in message
              news:40bf05ea$1@mktnews1...
              >
              > Reposting the message. Awaiting response from newsgroup or BEA
              > Thanks,
              > Sudarson
              > "sudarson" <[email protected]> wrote:
              > >
              > >Hello All,
              > >
              > >We tried to use wlsmqseries.zip classes (specially JNDI Mapper) for
              integrating
              > >WebLogic Server with MQ so that we can incorporate XA transactions. We
              > >use LDAP
              > >context factory to bind MQ.
              > >
              > >We found a number of LDAP connections are getting opened by JNDIMapper,
              > >but it's
              > >not getting closed.
              > >
              > >Can some one give some clue to this ?
              > >
              > >Also any suggestion to serve the current purpose is welcome.
              > >
              > >Thanks,
              > >Sudarson
              >
              

Maybe you are looking for

  • Crystal Reports XI: 6587706c SystemErr R Assertion Failed

    Hi: I am trying to incorporate Crystal Reports XI with in-house application, windows platform and Websphere Studio Application Development 5.1 and getting following errors. Most of the reports are coming up properly but the problem is it takes for ev

  • How can I dissable 'sponsored' tiles?

    With the new Firefox we got the very unwanted sponsored tiles. There were about 10 tiles that were placed for me. Some of them were even animated. Some nice spam right in your face on a screen you use regularly. There is a' gears' icon where you can

  • Release strategy(urgent)

    hi,    i have doubt regarding PO creation.   Purchase Order has to be approved after modidfication, but,       release strategy is not getting updated when i am modifying my PO......so i can't approve it.......... and i am chaning quantity,delivery d

  • Font is shown very small when using IE Tab and Windows Display is selected to show larger fonts

    I'm on Windows 7 - 64 bit and I set my Windows display to show larger fonts (from Control Panel, Display, then choose Larger Fonts). Now all pages show bigger fonts, except when I use IE Tab. I use IE Tab so that I can open my Microsoft Dynamics CRM

  • 10.4.8 broke FontBook

    Just did the combo update from 10.4.7 and all my fonts in the "Computer" section are off and I can't turn them on. They are in the /Library/Font folder but fontbook won't see them. It sees what is in my user folder, about 5 fonts. I trashed the fontb