Transaction and Weblogic MDB

Hi,
I am using Coherence as a cache for my weblogic application. I use a Message Driven Bean that receive a message, write something in Coherence and then write an other message in a result queue.
I want all this operations to be fully transactional. To do this I try to use the Coherence Container Integration with JCA (see http://wiki.tangosol.com/display/COH33UG/Transactions%2C+Locks+and+Concurrency).
My first problem here is to install the rar file in weblogic. I try in weblogic version 10 and 8.1 (my coherence version is 3.2) and I got the following errors :
in version 8.1
<13 juin 2007 15 h 51 CEST> <Error> <Deployer> <BEA-149201> <Failed to complete the deployment task with ID 1 for the application coherence-tx.
java.lang.NoClassDefFoundError: com/tangosol/util/WrapperException
in version 10 :
weblogic.connector.exception.RAConfigurationException: There are 1 nested errors: weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE FOUND /mnt/appli/bestofbreed/bea/user_projects/domains/bob_domain/servers/srv1/stage/coherence-tx/coherence-tx.rar/META-INF/ra.xml:36:4:36:4: problem: cvc-enumeration-valid: string value 'boolean' is not a valid enumeration value for config-property-typeType in namespace http://java.sun.com/xml/ns/j2ee: at weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(MarshallerFactory.java:234) at weblogic.descriptor.internal.MarshallerFactory$1.evaluateResults(MarshallerFactory.java:208) at weblogic.descriptor.internal.MarshallerFactory$1.createDescriptor(MarshallerFactory.java:146) at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:292) at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:260) at weblogic.descriptor.BasicDescriptorManager.createDescriptor(BasicDescriptorManager.java:322) at weblogic.application.descriptor.AbstractDescriptorLoader.createDescriptor(AbstractDescriptorLoader.java:347) at weblogic.application.descriptor.AbstractDescriptorLoader.createDescriptor(AbstractDescriptorLoader.java:331) at weblogic.application.descriptor.AbstractDescriptorLoader.getDescriptor(AbstractDescriptorLoader.java:240) at weblogic.application.descriptor.AbstractDescriptorLoader.getRootDescriptorBean(AbstractDescriptorLoader.java:220) at weblogic.connector.configuration.ConnectorDescriptor.getConnectorBean(ConnectorDescriptor.java:287) at weblogic.connector.configuration.DDUtil.getRAInfo(DDUtil.java:121) at weblogic.connector.deploy.ConnectorModule.loadDescriptors(ConnectorModule.java:747) at weblogic.connector.deploy.ConnectorModule.prepare(ConnectorModule.java:165) at weblogic.application.internal.flow.ModuleListenerInvoker.prepare(ModuleListenerInvoker.java:93) at weblogic.application.internal.flow.DeploymentCallbackFlow$1.next(DeploymentCallbackFlow.java:360) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:56) at weblogic.application.internal.flow.DeploymentCallbackFlow.prepare(DeploymentCallbackFlow.java:46) at weblogic.application.internal.BaseDeployment$1.next(BaseDeployment.java:615) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:26) at weblogic.application.internal.BaseDeployment.prepare(BaseDeployment.java:191) at weblogic.application.internal.DeploymentStateChecker.prepare(DeploymentStateChecker.java:147) at weblogic.deploy.internal.targetserver.AppContainerInvoker.prepare(AppContainerInvoker.java:61) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.createAndPrepareContainer(ActivateOperation.java:189) at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doPrepare(ActivateOperation.java:87) at weblogic.deploy.internal.targetserver.operations.AbstractOperation.prepare(AbstractOperation.java:217) at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentPrepare(DeploymentManager.java:719) at weblogic.deploy.internal.targetserver.DeploymentManager.prepareDeploymentList(DeploymentManager.java:1186) at weblogic.deploy.internal.targetserver.DeploymentManager.handlePrepare(DeploymentManager.java:248) at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.prepare(DeploymentServiceDispatcher.java:157) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doPrepareCallback(DeploymentReceiverCallbackDeliverer.java:157) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$000(DeploymentReceiverCallbackDeliverer.java:12) at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$1.run(DeploymentReceiverCallbackDeliverer.java:45) at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:464) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200) at weblogic.work.ExecuteThread.run(ExecuteThread.java:172)
Thanks,
Luc

Hi William,
Are you sure this is correct? During the prepare phase I would have expected the
changes to have been made persistent (durable within the grid) but not immediately
visible on at least another node within the cluster assuming Coherence is using the
grid itself as a transaction log service.What I wrote is how the TransactionMap API documentation describes it.
I believe, the idea behind it is that the commit phase writes data to the underlying cache with putAll and removeAll operations which are supposed to be fail-safe and are not waiting for any other threads if the client owns the locks for the entries, even in case of cluster node failures.
With the transaction consistency and isolation verified in prepare() and all relevant locks owned, there is no transactional reason why the commit could fail. The only possible causes of failure are disastrous conditions or errors in write-through cache store operations preventing success of the putAll/remove operations (or coding errors in serialization/deserialization/indexed-methods).
If not then how would Coherence ensure the commit would be successfully executed
after a voting to commit during the prepare phase even in the event of a failure
occurring before commit. The TransactionMap 2PC is not supposed to be interleaved with other 2PC operations. It is supposed to work only above the Coherence caches (actually you can add one 1PC operation between the TransactionMap prepare()-s and TransactionMap commit()-s, if you implement CacheFactory.commitTransactionCollection manually).
Full XA is not supported over the caches by Coherence.
The XA-related stuff I mentioned is when you use the Coherence CacheAdapter to enlist Coherence caches under a JTA transaction. However in this case the caches together act as a 1PC resource (JCA LocalTransaction mode) from the JTA TransactionManager-s point of view and you do not see anything from it being internally 2PC.
In this case, the JTA transaction 2PC operation proceeds as follows:
1. All real XA resources enlisted to the JTA transaction are prepared. After this point all JDBC changes over an XA-driver JDBC connection are flushed to the database, so all locks to be acquired are acquired.
2. If all were prepared successfully, then the transactional caches enlisted under the JCA Adapter are committed together with code equivalent to CacheFactory.commitTransactionCollection(). The transactional caches are practically TransactionMap-s wrapped in two or three layer of wrapper objects.
3. If the CacheFactory.commitTransactionCollection() succeeded, then all the XA resources enlisted to the JTA transaction are committed. All JDBC locks are released only at this point.
Why I mentioned XA and locks and TRANSACTION_EXTERNAL in this thread at all is that if you modified equivalent entries in Coherence to what you modified in XA JDBC, then you don't in fact need to lock those entries in Coherence, because equivalent locks with a broader lifetime are existing in the database. TRANSACTION_EXTERNAL allows you to do just that.
Hope this clears this up, but feel free to ask if it does not.
Best regards,
Robert

Similar Messages

MDB Container Managed Transaction and Log4J

Hi,
I'm programming and MDB that reads and updates a database then sends out an HTTP Post and logs using log4j. I've read that when an MDB is configured as CMT or container managed transaction and the OnMessage method executes without errors, the transaction is implicitly commited. You can rollback the transaction by explicitly calling setRollbackOnly() or when a RuntimeException has been thrown. My worry is that after I have sent out an HTTP POST (a transaction has been completed) I would have to log a transaction completion using log4j. My problems is if log4j throws a RuntimeException thereby rolling back my transaction which shouldn't be the case. What I have done is to catch all Exceptions (and swallow them) whenever I log using log4j after I have sent out an HTTP POST succesfully (since my transaction should be complete by then). Is this a correct workaround?
Thanks :)

Your approach is correct. If you think, Log4J might throw errors, swallow the exceptions and try not to roll back.

Mqseries and weblogic: XA transactions with MessagingBridge

Hello.
          Due to usage of XA transaction with MQSeries on host rather that weblogic host, require Extended Transactional Client - i have tried to use MessagingBridge feature in weblogic8.1.
          So, when we send message to JMS queue (source destination for messaging bridge) in transactional context it will be forwarded to MQSeries destination only after commit transaction. And if transaction will be crashed, MessagingBridge will not forward message from JMS to MQSeries.
          It is good substitution for XA transactions with MQSeries, i hope.
          In config.xml it looks like
          <BridgeDestination
          AdapterJNDIName="eis.jms.WLSConnectionFactoryJNDIXA"
          Name="mq_q_xa_bridgeQueue" Properties="DestinationJNDI=TEST2;DestinationType=Queue;ConnectionURL=file:/c:/jndidir;InitialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory;ConnectionFactoryJNDI=QCF2"/>
          <JMSBridgeDestination
          ConnectionFactoryJNDIName="thqueueconnectionfactory"
          DestinationJNDIName="bridgequeue" Name="THbridgequeue"/>
          <MessagingBridge AsyncEnabled="false" Name="wls2mqXA"
          QOSDegradationAllowed="false" QualityOfService="Exactly-once"
          SourceDestination="THbridgequeue" Started="true"
          TargetDestination="mq_q_xa_bridgeQueue" Targets="cgServer"/>
          And this implementation of XA transaction in weblogic+mqseries work.
          Does it have any bugs or hole or another disadvantages?
          Thanks.
          btw, i have found some interesting product at https://jmsbridgesxa.projects.dev2dev.bea.com/.
          But it not works on my environment (weblogic and mqseries on different hosts)

Hello.
          Due to usage of XA transaction with MQSeries on host rather that weblogic host, require Extended Transactional Client - i have tried to use MessagingBridge feature in weblogic8.1.
          So, when we send message to JMS queue (source destination for messaging bridge) in transactional context it will be forwarded to MQSeries destination only after commit transaction. And if transaction will be crashed, MessagingBridge will not forward message from JMS to MQSeries.
          It is good substitution for XA transactions with MQSeries, i hope.
          In config.xml it looks like
          <BridgeDestination
          AdapterJNDIName="eis.jms.WLSConnectionFactoryJNDIXA"
          Name="mq_q_xa_bridgeQueue" Properties="DestinationJNDI=TEST2;DestinationType=Queue;ConnectionURL=file:/c:/jndidir;InitialContextFactory=com.sun.jndi.fscontext.RefFSContextFactory;ConnectionFactoryJNDI=QCF2"/>
          <JMSBridgeDestination
          ConnectionFactoryJNDIName="thqueueconnectionfactory"
          DestinationJNDIName="bridgequeue" Name="THbridgequeue"/>
          <MessagingBridge AsyncEnabled="false" Name="wls2mqXA"
          QOSDegradationAllowed="false" QualityOfService="Exactly-once"
          SourceDestination="THbridgequeue" Started="true"
          TargetDestination="mq_q_xa_bridgeQueue" Targets="cgServer"/>
          And this implementation of XA transaction in weblogic+mqseries work.
          Does it have any bugs or hole or another disadvantages?
          Thanks.
          btw, i have found some interesting product at https://jmsbridgesxa.projects.dev2dev.bea.com/.
          But it not works on my environment (weblogic and mqseries on different hosts)

Problem integrating Oracle 9i and Weblogic 7 with MDBs

All:
I would really appreciate an answer to this question.
Background:
- We are using Oracle 9i and Weblogic 7
- I have an MDB that receives a message, then in the onMessage(Message) method
performs a findByPrimaryKey(String).
Problem:
The deployment descriptors and the MDB all work fine when I set them up to query
against a Pointbase database and deploy to Weblogic. Everything worked fine. But
this was only a test to see if everything would work.
I now need to query against an Oracle database. I got the updated version of the
Oracle Thin Driver and put it in the WL_HOME/server/lib/classes12.zip file. I
even added it to the beginning of the classpath in the startWeblogic.cmd file.
But am still having problems.
To test the just the Oracle connection I double checked the user, password, URL,
and driver settings in a java file using JDBC connections - and they worked fine.
They just aren't working when integrated into Weblogic.
The problem lies in the Weblogic 7 server integration with Oracle 9i. The software
integrated fine when tables from a Pointbase database were queried. The only changes
made have been to make the connectivity to Oracle.
My errors are in the attached myserver.log file. If anyone knows if this is a
known problem or what the problem is please let me know.
Just FYI my settings are as follows:
Driver: oracle.jdbc.driver.OracleDriver
URL=jdbc:oracle:thin:@192.168.6.10:1521:proType1
user=protype1
password=protype1
Any advice is welcomed! I've tried everything I can think of.
Angie
[myserver_errors.txt]

Hi Angela
you can try the following parameters in the FileRealm.properties to set
acl.reserve.weblogic.jdbc.connectionPool.<connectionPool>=everyone
Thomas
Angela Biche schrieb:
Thanks, I set the initial pool count to 2 and have up to 10
connections (for this testing). Unfortunately it hasn't helped
any.
The error that I am getting is an SQLException:
Exception = Access not allowed
But when I ran the java utils.dbping it makes the connection
with the connection and driver parameters I enter in the console.
I'm still open to ideas on this! :)
Thanks,
Angie

Use transacted session in MDB

          Hi,
          If I use transacted session in MDB with container managed transaction, dose the
          weblogic ignore the transacted setting or start in it's own transaction. I looked
          the JMS Tutorial from Sun, the J2EE server just ignore the transacted setting,
          treated it as non-transacted session.
          Thanks


          Thanks, Greg. I created another XAQCF in MQ JMSADMIN, but still did not help. The
          strange part is when this exception happens, in the Event Viewer there is a Message:
          An internal Websphere MQ Error has occurred'. In the Trace Log of MQ, the Major
          Error Code reported is arcE_XAER_PROTO.
          Has anyone encountered this error? The same code works fine when enlist an XAQCF
          defined in Weblogic and PUT into a Weblogic JMS Queue instead within the same
          XA Transaction. I am attaching the stack trace to this message, just in case,
          someone has useful pointers to help me. May be this is MQ Specific though I made
          sure I have the latest FixPack for MQ installed.
          Thanks,
          Sridhar
          "Greg Brail" <[email protected]> wrote:
          >Yeah. This comes up from time to time. MQ is upset because it wants to
          >be
          >enlisted in the JTA transaction, but JTA is not enlisting it because
          >it
          >thinks it's already enlisted. It thinks it's already enlisted because
          >the
          >same MQ connection factory was used for the MDB input queue, even though
          >it's a different JMS connection and session.
          >
          >You can avoid this by creating another "XAQCF" object in the MQ JNDI
          >space
          >and giving it a different name. If you do that -- essentially use different
          >connection factories for the MDB's input and output queues -- then this
          >will
          >work.
          >
          >Also, the transaction enlistement code in 8.1 that supports the
          >"resource-ref" feature avoids this problem.
          >
          > greg
          >
          >"Sridhar Krishnaswamy" <[email protected]> wrote in message
          >news:[email protected]...
          >>
          >> Hi Greg:
          >> I assume you meant to getXAResource() from an Object of type
          >XAQueueSession. Here
          >> is the code I tried within the onMessage() method of the MDB:
          >>
          >> XAQueueConnectionFactory factory = (XAQueueConnectionFactory)
          >ctx.lookup("XAQCF")
          >> ;
          >> XAConnection connection = factory.createXAQueueConnection() ;
          >>
          >> XAQueueSession mqSession = connection.createXAQueueSession() ;
          >> XAResource mqResource = mqSession.getXAResource() ;
          >> Transaction tran = TxHelper.getTransaction() ;
          >> tran.enlist(mqResource) ;
          >>
          >> //Then I was going to get the QueueSession Object from XAQueueSession,
          >obtain
          >> the Queue
          >> //Object from JNDI, create the Sender
          >> //and call the send. But I commented out these calls. Even then, after
          >the
          >onMessage
          >> Method
          >> // completes, I get the following error:
          >>
          >> javax.transaction.SystemException: start() failed on resource
          >'com.ibm.mq.MQXAResource':
          >> XAER_PROT : Routine was invoked in an improper context
          >> javax.transaction.xa.XAException: XA Operation failed. see errorcode
          >(which I
          >> am assuming is XAER_PROT).
          >>
          >> Any idea, what I am doing wrong?
          >>
          >>
          >>
          >>
          >> "Greg Brail" <[email protected]> wrote:
          >> >In 7.0, you can do your MQ "put" inside the same JTA transaction that
          >> >was
          >> >used to receive the message for the MDB, but you have to do the
          >transaction
          >> >enlistment yourself. Basically, you have to use the class
          >> >weblogic.transaction.TxHelper class to get a reference to the current
          >> >transaction, then call "enlistResource" on the transaction using the
          >> >JTA
          >> >"XAResource" that you get from the MQ JMS "Session" object. I'm sure
          >> >we've
          >> >posted the code in this newsgroup before, but I don't know where,
          >so
          >> >it
          >> >would look something like:
          >> >
          >> >// First, get the MQ QueueSession object you're going to use to send
          >> >the
          >> >message
          >> >QueueSession mqSession = mqConnection.createQueueSession(false, 0);
          >> >XAResource mqResource = mqSession.getXAResource();
          >> >weblogic.transaction.Transaction tran =
          >> >weblogic.transaction.TxHelper.getTransaction();
          >> >tran.enlistResource(mqResource);
          >> >// Now send your message
          >> >
          >> >In 8.1, this will still work, but it's not necessary. If you register
          >> >the MQ
          >> >XA connection factory as a "resource-reference" in your EJB deployment
          >> >descriptors and look it up using java:comp/env the way the documentation
          >> >link way below describes, then this transaction enlistment happens
          >> >automatically. This only happens when you use the "resource-reference"
          >> >feature (which means that old code will still work if it does NOT
          >use
          >> >this
          >> >feature), and it's only in 8.1.
          >> >
          >> > greg
          >> >
          >> >"Sridhar Krishnaswamy" <[email protected]> wrote in
          >message
          >> >news:[email protected]...
          >> >>
          >> >> Hi Greg:
          >> >> Is the Statement
          >> >>
          >> >> 'But in this case, you don't get a "non-transactional" session,
          >but
          >> >actually a
          >> >> session that participates in the current JTA transaction for the
          >thread
          >> >where
          >> >> your EJB is running'
          >> >>
          >> >> also true in the case of an MDB running in Weblogic 7.0 (Container
          >> >Managed
          >> >Transactions)
          >> >> driven by an XAQCF and a Foreign JMS Provider such as MQSeries?
          >In
          >> >other
          >> >words,
          >> >> if I want the MDB to PUT the Message into an MQSeries Queue, can
          >the
          >> >PUT
          >> >be invoked
          >> >> under the Context of the Same XA Transaction? My understanding is
          >that
          >> >WebLogic
          >> >> 7.0 doesn't support send
          >> >> messages out of an MDB within the same XA transaction if the MDB
          >is
          >> >> XA-driven by a foreign JMS provider. Please let me know if this
          >is
          >> >false.
          >> >If true,
          >> >> does Weblogic 8.1 also have this restriction?
          >> >>
          >> >> Thanks,
          >> >> Sridhar Krishnaswamy.
          >> >>
          >> >> "Greg Brail" <[email protected]> wrote:
          >> >> >What do you mean by "use transacted session in MDB?" Are you creating
          >> >> >a new
          >> >> >session inside your MDB, or do you mean something else?
          >> >> >
          >> >> >The only Sun thing I can think of is in code that looks like this:
          >> >> >
          >> >> >InitialContext ctx = new InitialContext();
          >> >> >QueueConnectionFactory qcf = ctx.lookup("java:comp/env/jms/QCF");
          >> >> >Queue queue = ctx.lookup("java:comp/env/jms/Queue");
          >> >> >QueueConnection connection = qcf.createQueueConnection();
          >> >> >// Create "transacted" session:
          >> >> >QueueSession session = connection.createQueueSession(true, 0);
          >> >> >QueueSender sender = session.createQueueSender(queue);
          >> >> >TextMessage message = session.createTextMessage("Hello, world");
          >> >> >sender.send(message);
          >> >> >connection.close();
          >> >> >
          >> >> >If you do this, and exactly this, inside an EJB, including the
          >use
          >> >of
          >> >> >"java:comp/env/jms", in WebLogic Server 8.1, then we do indeed
          >ignore
          >> >> >the
          >> >> >"transacted" flag when you create the session, just like Sun says
          >> >we
          >> >> >should
          >> >> >in the EJB and J2EE specs. But in this case, you don't get a
          >> >> >"non-transactional" session, but actually a session that participates
          >> >> >in the
          >> >> >current JTA transaction for the thread where your EJB is running.
          >> >> >
          >> >> >The idea is that if you are working inside an EJB, you don't use
          >> >transacted
          >> >> >sessions -- you use the transaction control given to you by the
          >EJB
          >> >> >container, including the UserTransaction interface and/or the various
          >> >> >container-managed transaction flags, rather than the JMS "transacted
          >> >> >session".
          >> >> >
          >> >> >You can find more information here:
          >> >> >
          >> >> >http://e-docs.bea.com/wls/docs81/jms/j2ee_components.html
          >> >> >
          >> >> > greg
          >> >> >
          >> >> >"Jen" <[email protected]> wrote in message
          >> >> >news:[email protected]...
          >> >> >>
          >> >> >> Hi,
          >> >> >>
          >> >> >> If I use transacted session in MDB with container managed
          >transaction,
          >> >> >dose the
          >> >> >> weblogic ignore the transacted setting or start in it's own
          >> >transaction.
          >> >> >I
          >> >> >looked
          >> >> >> the JMS Tutorial from Sun, the J2EE server just ignore the
          >transacted
          >> >> >setting,
          >> >> >> treated it as non-transacted session.
          >> >> >> Thanks
          >> >> >
          >> >> >
          >> >>
          >> >
          >> >
          >>
          >
          >
          [eRRORS.txt]

Transactions and database locks

Hi,
               We use Weblogic 4.5.1 on Windows NT 4.0 with Oracle 8.0.5. Our database
          isolation is set to TRANSACTION_READ_COMMITTED. I have an entity bean with
          TX_REQUIRED & TRANSACTION_READ_COMMITTED settings. If my client creates a
          transaction, and starts calling methods on this entity bean, is the
          corresponding database row locked for the duration of the transaction? We
          have concurrent SQl-plus sessions going on and we want make sure there is
          no data corruption. If the row is not locked, is it ok for me to explicitly
          lock it from inside my entity bean?
          Thanks,
          Srini.


Hi. This should have been posted to the EJB or JDBC group, but I'll take it.
          This is an Oracle question. If you have a transaction as you've described,
          then the behavior will be exactly as if you had multiple SQL-PLUS sessions,
          and in one of them, you did:
          SQL> BEGIN;
          -- do what your bean would do;
          SQL> COMMIT;
          You can test this there. In general, you'll find that Oracle's optimistic locking
          will allow any number of simutaneous transactions to access a given row
          at one time. Oracle does not lock the real data while a transaction is ongoing,
          instead making a copy for the client to work off of. At commit time, depending
          on the isolation level semantics, some or all of the transactions may fail when
          Oracle tries to update the real data from the per-session private data.
          I would council against running with SERIALIZABLE mode because there
          is a serious bug in Oracle, where serializable transactions may fail silently.
          Details on request.
          Joe
          Srini wrote:
          > Hi,
          > We use Weblogic 4.5.1 on Windows NT 4.0 with Oracle 8.0.5. Our database
          > isolation is set to TRANSACTION_READ_COMMITTED. I have an entity bean with
          > TX_REQUIRED & TRANSACTION_READ_COMMITTED settings. If my client creates a
          > transaction, and starts calling methods on this entity bean, is the
          > corresponding database row locked for the duration of the transaction? We
          > have concurrent SQl-plus sessions going on and we want make sure there is
          > no data corruption. If the row is not locked, is it ok for me to explicitly
          > lock it from inside my entity bean?
          >
          > Thanks,
          > Srini.
          PS: Folks: BEA WebLogic is in S.F., and now has some entry-level positions for
          people who want to work with Java and E-Commerce infrastructure products. Send
          resumes to [email protected]
          The Weblogic Application Server from BEA
          JavaWorld Editor's Choice Award: Best Web Application Server
          Java Developer's Journal Editor's Choice Award: Best Web Application Server
          Crossroads A-List Award: Rapid Application Development Tools for Java
          Intelligent Enterprise RealWare: Best Application Using a Component Architecture
          http://weblogic.beasys.com/press/awards/index.htm

Transactions in Weblogic 5.1

Hi there,
          I'm fiddling a bit with transactions in Weblogic 5.1, and I might have
          misunderstood a few things, 'cause it seems like Weblogic is not doing
          the right thing.
          I have this entity bean that does not do any database connects, in fact
          it does not use any TX resources, but I'd like to serialize access to it
          anyway - and I had the impression that the Weblogic server could do this
          for me. Having the entity bean deployed with "Mandatory" transcation and
          "Serializable" isolation level does however not give me the desired
          result - I can hold the entity bean in multiple transaction contexts :-(
          So for me it seems like Weblogic Server 5.1 does not do any transaction
          serialization by itself, and documentation I have stumbled upon indicate
          that the server relies on JDBC drivers and such to provide transaction
          isolation. Seems like the entity bean itself is not considered a
          TxResource whereas an underlying database connection is.
          Am I right? -- if I am, does this mean that in order to serialize access
          under transaction to an entity bean I must have data base access?
          regards
          Jakob


          Hi Jacob,
          Transaction isolation levels are ment for database transactions only..but the
          transaction attributes not the same..you can apply
          the transaction attributes to session bean which may not access db at alll
          Thanks
          Ramesh
          Jakob Dalsgaard <[email protected]> wrote:
          >Hi there,
          >
          >I'm fiddling a bit with transactions in Weblogic 5.1, and I might have
          >
          >misunderstood a few things, 'cause it seems like Weblogic is not doing
          >
          >the right thing.
          >
          >I have this entity bean that does not do any database connects, in fact
          >
          >it does not use any TX resources, but I'd like to serialize access to
          >it
          >anyway - and I had the impression that the Weblogic server could do this
          >
          >for me. Having the entity bean deployed with "Mandatory" transcation
          >and
          >"Serializable" isolation level does however not give me the desired
          >result - I can hold the entity bean in multiple transaction contexts
          >:-(
          >
          >So for me it seems like Weblogic Server 5.1 does not do any transaction
          >
          >serialization by itself, and documentation I have stumbled upon indicate
          >
          >that the server relies on JDBC drivers and such to provide transaction
          >
          >isolation. Seems like the entity bean itself is not considered a
          >TxResource whereas an underlying database connection is.
          >
          >Am I right? -- if I am, does this mean that in order to serialize access
          >
          >under transaction to an entity bean I must have data base access?
          >
          >regards
          >Jakob
          >

Session Beans and TIBCO E4JMS and Weblogic JMS 8.1

          Setup:-
          Weblogic Server 8.1 SP2 on Linux
          TIBCO E4JMS 3.1.2
          I have a two Staeless Session Beans which are deployed in both sides of the cluster
          - Cluster is made up of two servers(ManagedServer1 and ManagedServer2) on the
          same machine. The beans have container managed transaction and trans-type set
          to required. The JMS Server is on ManagedServer1. The session bean publishes 100
          messages to TIBCO JMS and Weblogic JMS and calls the second bean which again publishes
          100 messages to TIBCO JMS and Weblogic JMS .
          The connection factories used are XAQueueConnectionFactories.
          This seems to work under the following conditions:-
          a) The session beans are deployed just in ManagedServer1
          b) The WL load balancing scheme manages to run both the beans on ManagedServer1
          c) If I don't publish onto Weblogic JMS( It runs successfully on ManagedServer1
          and ManagedServer2)
          It does not seems to work :-
          When the The WL load balancing scheme manages to run both the beans on ManagedServer2.I
          put debug statements on the beans and it seems to publish everything but fails
          during the commit
          murali@dbuslinux1:~/SessionBeanExample> ant run
          Buildfile: build.xml
          run:
          [java] Run : 0
          [java] InitialContextFactory weblogic.jndi.WLInitialContextFactory
          [java] Provider Url t3://myhost.mycompany.com:18003,myhost.mycompany.com:18005
          [java] javax.transaction.TransactionRolledbackException: Exception while
          commiting Tx : Name=[EJB Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer,java.lang.String,boolean,boolean)],Xid=BEA1-000649EC8876A0032A5E(160401684),Status=Rolled
          back. [Reason=javax.transaction.xa.XAException],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds
          since begin=3,seconds left=30,XAServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN1TCF]=(ServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN1TCF]=(state=rolledback,assigned=ManagedServer2),xar=weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource@a0181b0),XAServerResourceInfo[JMS_MyJMS
          File Store]=(ServerResourceInfo[JMS_MyJMS File Store]=(state=rolledback,assigned=ManagedServer1),xar=null),XAServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(ServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(state=rolledback,assigned=ManagedServer2),xar=weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource@98f6821),SCInfo[E4JMSDOMAIN+ManagedServer1]=(state=rolledback),SCInfo[E4JMSDOMAIN+ManagedServer2]=(state=rolledback),properties=({weblogic.transaction.name=[EJB
          Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer,java.lang.String,boolean,boolean)]}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=ManagedServer2+myhost.mycompany.com:18005+E4JMSDOMAIN+t3+,
          XAResources={},NonXAResources={})],CoordinatorURL=ManagedServer2+myhost.mycompany.com:18005+E4JMSDOMAIN+t3+):
          javax.transaction.xa.XAException
          [java] at com.tibco.tibjms.TibjmsXAResource.end(Ljavax.transaction.xa.Xid;I)V(TibjmsXAResource.java:157)
          [java] at weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.end(Ljavax.transaction.xa.Xid;I)V(Unknown
          Source)
          [java] at weblogic.transaction.internal.XAServerResourceInfo.end(Lweblogic.transaction.internal.ServerTransactionImpl;Ljavax.transaction.xa.Xid;I)V(XAServerResourceInfo.java:1124)
          [java] at weblogic.transaction.internal.XAServerResourceInfo.internalDelist(Lweblogic.transaction.internal.ServerTransactionImpl;I)V(XAServerResourceInfo.java:325)
          [java] at weblogic.transaction.internal.XAServerResourceInfo.delist(Lweblogic.transaction.internal.ServerTransactionImpl;IZ)V(XAServerResourceInfo.java:255)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(IZ)V(ServerTransactionImpl.java:1408)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(I)V(ServerTransactionImpl.java:1396)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.globalPrepare()V(ServerTransactionImpl.java:1932)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.internalCommit()V(ServerTransactionImpl.java:252)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.commit()V(ServerTransactionImpl.java:221)
          [java] at weblogic.ejb20.internal.BaseEJBObject.postInvoke(Lweblogic.ejb20.interfaces.InvocationWrapper;Ljava.lang.Throwable;)V(BaseEJBObject.java:289)
          [java] at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(Lweblogic.ejb20.interfaces.InvocationWrapper;Ljava.lang.Throwable;)V(StatelessEJBObject.java:141)
          [java] at Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Ljava.lang.Integer;Ljava.lang.Integer;Ljava.lang.String;ZZ)V(Stateless_soycq8_EOImpl.java:112)
          [java] at Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(ILweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object;)Lweblogic.rmi.spi.OutboundResponse;(Unknown
          Source)
          [java] at weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;)V(BasicServerRef.java:477)
          [java] at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;)V(ReplicaAwareServerRef.java:108)
          [java] at weblogic.rmi.internal.BasicServerRef$1.run()Ljava.lang.Object;(BasicServerRef.java:420)
          [java] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.subject.AbstractSubject;Ljava.security.PrivilegedExceptionAction;)Ljava.lang.Object;(AuthenticatedSubject.java:353)
          [java] at weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.internal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubject;Ljava.security.PrivilegedExceptionAction;)Ljava.lang.Object;(SecurityManager.java:144)
          [java] at weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.InboundRequest;)V(BasicServerRef.java:415)
          [java] at weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteThread;)V(BasicExecuteRequest.java:30)
          [java] at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(ExecuteThread.java:197)
          [java] at weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:170)
          [java] at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown
          Source)
          [java] ; nested exception is:
          [java] javax.transaction.xa.XAException
          [java] at weblogic.rjvm.BasicOutboundRequest.sendReceive()Lweblogic.rmi.spi.InboundResponse;(BasicOutboundRequest.java:108)
          [java] at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Lweblogic.rmi.extensions.server.RemoteReference;Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;[Ljava.lang.Object;Ljava.lang.reflect.Method;)Ljava.lang.Object;(ReplicaAwareRemoteRef.java:284)
          [java] at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Ljava.rmi.Remote;Lweblogic.rmi.extensions.server.RuntimeMethodDescriptor;[Ljava.lang.Object;Ljava.lang.reflect.Method;)Ljava.lang.Object;(ReplicaAwareRemoteRef.java:244)
          [java] at Case463495.Stateless_soycq8_EOImpl_812_WLStub.sendMessageWrap(Ljava.lang.Integer;Ljava.lang.Integer;Ljava.lang.String;ZZ)V(Unknown
          Source)
          [java] at Case463495.Client.run()V(Client.java:103)
          [java] at Case463495.Client.sendMessage()V(Client.java:132)
          [java] at Case463495.Client.main([Ljava.lang.String;)V(Client.java:195)
          [java] Caused by: javax.transaction.xa.XAException
          [java] at com.tibco.tibjms.TibjmsXAResource.end(TibjmsXAResource.java:157)
          [java] at weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.end(Unknown
          Source)
          [java] at weblogic.transaction.internal.XAServerResourceInfo.end(XAServerResourceInfo.java:1124)
          [java] at weblogic.transaction.internal.XAServerResourceInfo.internalDelist(XAServerResourceInfo.java:325)
          [java] at weblogic.transaction.internal.XAServerResourceInfo.delist(XAServerResourceInfo.java:255)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransactionImpl.java:1408)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransactionImpl.java:1396)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.globalPrepare(ServerTransactionImpl.java:1932)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:252)
          [java] at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:221)
          [java] at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:289)
          [java] at weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.java:141)
          [java] at Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Stateless_soycq8_EOImpl.java:112)
          [java] at Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(Unknown Source)
          [java] at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
          [java] at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:108)
          [java] at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
          [java] at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:353)
          [java] at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
          [java] at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
          [java] at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30)
          [java] at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
          [java] at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          [java] at java.lang.Thread.startThreadFromVM(Unknown Source)
          Apologies in advance if this need to be posted in the JTA news group..
          Any ideas?
          Murali


Posting to the transaction newsgroup would probably also be helpful.
          Can you post the code for the session bean so we can see how you're
          enlisting Tibco in the transaction? It looks like you're using the JMS
          provider wrappers from 8.1, which do the transaction enlistment for you, so
          you shouldn't need to mess with JTA at all in your code. Still, something
          weird is going on and it'd be nice to see exactly what your code looks like.
          greg
          "L Muralidharan" <[email protected]> wrote in message
          news:[email protected]...
          >
          > Setup:-
          >
          > Weblogic Server 8.1 SP2 on Linux
          >
          > TIBCO E4JMS 3.1.2
          >
          > I have a two Staeless Session Beans which are deployed in both sides of
          the cluster
          > - Cluster is made up of two servers(ManagedServer1 and ManagedServer2) on
          the
          > same machine. The beans have container managed transaction and trans-type
          set
          > to required. The JMS Server is on ManagedServer1. The session bean
          publishes 100
          > messages to TIBCO JMS and Weblogic JMS and calls the second bean which
          again publishes
          > 100 messages to TIBCO JMS and Weblogic JMS .
          >
          > The connection factories used are XAQueueConnectionFactories.
          >
          > This seems to work under the following conditions:-
          >
          > a) The session beans are deployed just in ManagedServer1
          > b) The WL load balancing scheme manages to run both the beans on
          ManagedServer1
          > c) If I don't publish onto Weblogic JMS( It runs successfully on
          ManagedServer1
          > and ManagedServer2)
          >
          > It does not seems to work :-
          >
          > When the The WL load balancing scheme manages to run both the beans on
          ManagedServer2.I
          > put debug statements on the beans and it seems to publish everything but
          fails
          > during the commit
          >
          > murali@dbuslinux1:~/SessionBeanExample> ant run
          > Buildfile: build.xml
          >
          > run:
          > [java] Run : 0
          > [java] InitialContextFactory weblogic.jndi.WLInitialContextFactory
          > [java] Provider Url
          t3://myhost.mycompany.com:18003,myhost.mycompany.com:18005
          > [java] javax.transaction.TransactionRolledbackException: Exception
          while
          > commiting Tx : Name=[EJB
          Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer
          ,java.lang.String,boolean,boolean)],Xid=BEA1-000649EC8876A0032A5E(160401684)
          ,Status=Rolled
          > back.
          [Reason=javax.transaction.xa.XAException],numRepliesOwedMe=0,numRepliesOwedO
          thers=0,seconds
          > since begin=3,seconds
          left=30,XAServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEA
          N1TCF]=(ServerResourceInfo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN1
          TCF]=(state=rolledback,assigned=ManagedServer2),xar=weblogic.deployment.jms.
          WrappedXAResource_com_tibco_tibjms_TibjmsXAResource@a0181b0),XAServerResourc
          eInfo[JMS_MyJMS
          > File Store]=(ServerResourceInfo[JMS_MyJMS File
          Store]=(state=rolledback,assigned=ManagedServer1),xar=null),XAServerResource
          Info[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(ServerResourceIn
          fo[E4JMSDOMAIN.ManagedServer2.JMSXASessionPool.BEAN2TCF]=(state=rolledback,a
          ssigned=ManagedServer2),xar=weblogic.deployment.jms.WrappedXAResource_com_ti
          bco_tibjms_TibjmsXAResource@98f6821),SCInfo[E4JMSDOMAIN+ManagedServer1]=(sta
          te=rolledback),SCInfo[E4JMSDOMAIN+ManagedServer2]=(state=rolledback),propert
          ies=({weblogic.transaction.name=[EJB
          >
          Case463495.StatelessBean.sendMessageWrap(java.lang.Integer,java.lang.Integer
          ,java.lang.String,boolean,boolean)]}),OwnerTransactionManager=ServerTM[Serve
          rCoordinatorDescriptor=(CoordinatorURL=ManagedServer2+myhost.mycompany.com:1
          8005+E4JMSDOMAIN+t3+,
          >
          XAResources={},NonXAResources={})],CoordinatorURL=ManagedServer2+myhost.myco
          mpany.com:18005+E4JMSDOMAIN+t3+):
          > javax.transaction.xa.XAException
          > [java] at
          com.tibco.tibjms.TibjmsXAResource.end(Ljavax.transaction.xa.Xid;I)V(TibjmsXA
          Resource.java:157)
          > [java] at
          weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.
          end(Ljavax.transaction.xa.Xid;I)V(Unknown
          > Source)
          > [java] at
          weblogic.transaction.internal.XAServerResourceInfo.end(Lweblogic.transaction
          .internal.ServerTransactionImpl;Ljavax.transaction.xa.Xid;I)V(XAServerResour
          ceInfo.java:1124)
          > [java] at
          weblogic.transaction.internal.XAServerResourceInfo.internalDelist(Lweblogic.
          transaction.internal.ServerTransactionImpl;I)V(XAServerResourceInfo.java:325
          > [java] at
          weblogic.transaction.internal.XAServerResourceInfo.delist(Lweblogic.transact
          ion.internal.ServerTransactionImpl;IZ)V(XAServerResourceInfo.java:255)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.delistAll(IZ)V(ServerTra
          nsactionImpl.java:1408)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.delistAll(I)V(ServerTran
          sactionImpl.java:1396)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.globalPrepare()V(ServerT
          ransactionImpl.java:1932)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.internalCommit()V(Server
          TransactionImpl.java:252)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.commit()V(ServerTransact
          ionImpl.java:221)
          > [java] at
          weblogic.ejb20.internal.BaseEJBObject.postInvoke(Lweblogic.ejb20.interfaces.
          InvocationWrapper;Ljava.lang.Throwable;)V(BaseEJBObject.java:289)
          > [java] at
          weblogic.ejb20.internal.StatelessEJBObject.postInvoke(Lweblogic.ejb20.interf
          aces.InvocationWrapper;Ljava.lang.Throwable;)V(StatelessEJBObject.java:141)
          > [java] at
          Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Ljava.lang.Integer;Ljava.
          lang.Integer;Ljava.lang.String;ZZ)V(Stateless_soycq8_EOImpl.java:112)
          > [java] at
          Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(ILweblogic.rmi.spi.InboundR
          equest;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object;)Lweblogic.rmi.s
          pi.OutboundResponse;(Unknown
          > Source)
          > [java] at
          weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.extensions.server.
          RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.O
          utboundResponse;)V(BasicServerRef.java:477)
          > [java] at
          weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(Lweblogic.rmi.extensions.s
          erver.RuntimeMethodDescriptor;Lweblogic.rmi.spi.InboundRequest;Lweblogic.rmi
          .spi.OutboundResponse;)V(ReplicaAwareServerRef.java:108)
          > [java] at
          weblogic.rmi.internal.BasicServerRef$1.run()Ljava.lang.Object;(BasicServerRe
          f.java:420)
          > [java] at
          weblogic.security.acl.internal.AuthenticatedSubject.doAs(Lweblogic.security.
          subject.AbstractSubject;Ljava.security.PrivilegedExceptionAction;)Ljava.lang
          .Object;(AuthenticatedSubject.java:353)
          > [java] at
          weblogic.security.service.SecurityManager.runAs(Lweblogic.security.acl.inter
          nal.AuthenticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubjec
          t;Ljava.security.PrivilegedExceptionAction;)Ljava.lang.Object;(SecurityManag
          er.java:144)
          > [java] at
          weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.Inbound
          Request;)V(BasicServerRef.java:415)
          > [java] at
          weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteTh
          read;)V(BasicExecuteRequest.java:30)
          > [java] at
          weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(Exe
          cuteThread.java:197)
          > [java] at
          weblogic.kernel.ExecuteThread.run()V(ExecuteThread.java:170)
          > [java] at
          java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown
          > Source)
          > [java] ; nested exception is:
          > [java] javax.transaction.xa.XAException
          > [java] at
          weblogic.rjvm.BasicOutboundRequest.sendReceive()Lweblogic.rmi.spi.InboundRes
          ponse;(BasicOutboundRequest.java:108)
          > [java] at
          weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Lweblogic.rmi.extensions.s
          erver.RemoteReference;Lweblogic.rmi.extensions.server.RuntimeMethodDescripto
          r;[Ljava.lang.Object;Ljava.lang.reflect.Method;)Ljava.lang.Object;(ReplicaAw
          areRemoteRef.java:284)
          > [java] at
          weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(Ljava.rmi.Remote;Lweblogic
          .rmi.extensions.server.RuntimeMethodDescriptor;[Ljava.lang.Object;Ljava.lang
          .reflect.Method;)Ljava.lang.Object;(ReplicaAwareRemoteRef.java:244)
          > [java] at
          Case463495.Stateless_soycq8_EOImpl_812_WLStub.sendMessageWrap(Ljava.lang.Int
          eger;Ljava.lang.Integer;Ljava.lang.String;ZZ)V(Unknown
          > Source)
          > [java] at Case463495.Client.run()V(Client.java:103)
          > [java] at Case463495.Client.sendMessage()V(Client.java:132)
          > [java] at
          Case463495.Client.main([Ljava.lang.String;)V(Client.java:195)
          > [java] Caused by: javax.transaction.xa.XAException
          > [java] at
          com.tibco.tibjms.TibjmsXAResource.end(TibjmsXAResource.java:157)
          > [java] at
          weblogic.deployment.jms.WrappedXAResource_com_tibco_tibjms_TibjmsXAResource.
          end(Unknown
          > Source)
          > [java] at
          weblogic.transaction.internal.XAServerResourceInfo.end(XAServerResourceInfo.
          java:1124)
          > [java] at
          weblogic.transaction.internal.XAServerResourceInfo.internalDelist(XAServerRe
          sourceInfo.java:325)
          > [java] at
          weblogic.transaction.internal.XAServerResourceInfo.delist(XAServerResourceIn
          fo.java:255)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransact
          ionImpl.java:1408)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.delistAll(ServerTransact
          ionImpl.java:1396)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.globalPrepare(ServerTran
          sactionImpl.java:1932)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTra
          nsactionImpl.java:252)
          > [java] at
          weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransaction
          Impl.java:221)
          > [java] at
          weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:289)
          > [java] at
          weblogic.ejb20.internal.StatelessEJBObject.postInvoke(StatelessEJBObject.jav
          a:141)
          > [java] at
          Case463495.Stateless_soycq8_EOImpl.sendMessageWrap(Stateless_soycq8_EOImpl.j
          ava:112)
          > [java] at
          Case463495.Stateless_soycq8_EOImpl_WLSkel.invoke(Unknown Source)
          > [java] at
          weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:477)
          > [java] at
          weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java
          :108)
          > [java] at
          weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:420)
          > [java] at
          weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubjec
          t.java:353)
          > [java] at
          weblogic.security.service.SecurityManager.runAs(SecurityManager.java:144)
          > [java] at
          weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:415)
          > [java] at
          weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:3
          0)
          > [java] at
          weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
          > [java] at
          weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
          > [java] at java.lang.Thread.startThreadFromVM(Unknown Source)
          >
          >
          > Apologies in advance if this need to be posted in the JTA news group..
          >
          > Any ideas?
          >
          > Murali
          >

Distributed Transaction in weblogic 5.1

Hi all,
Does Weblogic 5.1 support Distributed Transactions?.

While they aren't java-specific, if you're looking for XA/2PC details,
these 2 are good:
Transaction Processing: Concepts and Techniques (Morgan Kaufmann Series
in Data Management Systems)
by Jim Gray, Andreas Reuter
Principles of Transaction Processing
by Philip A. Bernstein, Eric Newcomer (Contributor)
5.1 does not support XA or 2 phase-commit. However, it does allow
multiple cluster members to enlist in the same transaction as long as
all database access goes through the same JDBC connection.
WLS 6.0 and later do support XA and 2PC.
-- Rob
chandrasekar wrote:
Hi all,
Does Weblogic 5.1 support Distributed Transactions?.Please suggest me some
books or documentation regarding Distributed Transactions, and about the XA compliant
resources.

Transaction in Weblogic 5.1 Server

          Hi All,
          Can any one tell me How to set XA DataSource details in weblogic.properties
          file in weblogic 5.1 server.
          Thanx
          Ramana Murthy


While they aren't java-specific, if you're looking for XA/2PC details,
these 2 are good:
Transaction Processing: Concepts and Techniques (Morgan Kaufmann Series
in Data Management Systems)
by Jim Gray, Andreas Reuter
Principles of Transaction Processing
by Philip A. Bernstein, Eric Newcomer (Contributor)
5.1 does not support XA or 2 phase-commit. However, it does allow
multiple cluster members to enlist in the same transaction as long as
all database access goes through the same JDBC connection.
WLS 6.0 and later do support XA and 2PC.
-- Rob
chandrasekar wrote:
Hi all,
Does Weblogic 5.1 support Distributed Transactions?.Please suggest me some
books or documentation regarding Distributed Transactions, and about the XA compliant
resources.

Clustered WebLogic MDB receiving multiple messages...

Hi all,
I have a JMS WebLogic clustering problem.
First, let me describe the problem. The MDB of my application (it's a simple test application to get the clustering kinks worked out) is listening to a Topic and when I publish a message to the Topic the MDB is receiving the message multiple times. I have a max of 4 managed servers in my cluster and when they are all running, each MDB on each managed server gets the message 4 times. If I shut down two of the managed servers, then each MDB on each of the two running managed servers get the message 2 times. So my MDB is receiving the message multiple times equal to the number of manged servers I have running in my cluster.
So my question is what is the proper way to configure JMS Servers for a cluster?
Next I want to explain how I start the managed servers in the cluster. At this time I am unable to use NodeManager so starting of the instances is done manually via command line. Basically it's a wrapper around the startManagedWebLogic.sh script. I know something is wrong with my JMS configuration because when I start the managed servers I will typically see an error which looks like this:
<Warning> <EJB> <BEA-010061> <The Message-Driven EJB: MyMDB is unable to connect ot the JMS destination: jms/myTopic. The error was:
werblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.jms.common.JMSException: could not find Server NAME_OF_MANAGED_SERVER
Nested exception: weblogic.messaging.dispatcher.DispatcherException: could not find Server NAME_OF_MANAGED_SERVER
Nested excpetion: javax.naming.NameNotFoundException: Unable to resolve 'weblogic.messaging.dispatcher.S:NAME_OF_MANAGED_SERVER'. Resolved 'weblogic.messaging.dispatcher'; remaining name 'S:NAME_OF_MANAGED_SERVER'>
Despite this error message, the MDB on that manged server does still successfully recieve messages posted to the Topic, though, as stated earlier, my problem is the MDB is getting the message more than once.
Also, I've confirmed all managed servers in the cluster can receive the message posted to the Topic no matter which managed server posts the original message.
Next is to explain my cluster configuration. I'm sure I know is is wrong, but not sure where my mistake is. Here is my JMS configuration for the cluster.
4 JMS Servers
Persistence Store:
Each JMS Server has its own persistent store
Each store targets one of the 4 (migratable) managed servers
Each store is a FileStore
Filesystem is not shared between VMs in the cluster
Target:Each JMS server targets one of the 4 (migratable) managed servers
1 JMS ModuleTarget: The cluster - "All servers in the cluster"
1 JMS Topic
Destination type: Uniform
Forwarding Policy: Replicated
Template: None
Target: The cluster - "All servers in the cluster"
Subdeployment: Default Targeting
1 JMS ConnectionFactory
Subscription Sharing Policy: Exclusive
Client ID Policy: Restricted
XA connection factory enabled (YES)
Target: The cluster - "All servers in the cluster"
Subdeployment: Default Targeting

Hi Michael,
I need to clarify exactly what you want to happen. What you are saying you want is not typical. I expected you to say you wanted Scenario 8 or 9. Those are the most common.
I will try to capture what your words are saying in "graphic text". I'm not sure that the graphic in the document is accurate.
Server 1                      Server 2                      Server 3                      Server 4
JMS svr 1                    JMS svr 2                   JMS svr 3                    JMS svr 4
DistTopic-mem1         DistTopic-mem2          DistTopic-mem3          DistTopic-mem4
MDB listens locally     MDB listens locally      MDB listens locally      MDB listens locally
Events...
1. Message published
on Server 1
2. Message is replicated
to server 2
3. Local MDB get message
                                  4. Message is replicated
                                  to server 3
                                  5. Local MDB gets message
                                                                      6. Message is replicated
                                                                      to Server 4
                                                                      7. Local MDB gets the message
                                                                                                            8. Local MDB gets the message.
This is the standard Replicated Distributed Topic flow. Messages are replicated, and every message is forwarded to every member of the distributed topic.
In the case, each message will be processed 4 times - once per server.
This is what your text says you want.
This is scenario 1 in the doc.
I don't really know what is going wrong with your MDB. The topics are getting created per your comment about the ability to publish a message.
Are you seeing errors during deployment?
To answer your question about where to set topicMessagesDistributionMode and distributedDestinationConnection, they are set in a deployment descriptor or in an annotation in the MDB. See http://docs.oracle.com/middleware/1213/wls/WLMDB/summary.htm#WLMDB1385..
Let me know if I described what you want to happen.
If so, a replicated distributed topic and an MDB deployed to the cluster should just work with no need to set the descriptor elements.
Dave

AQ transactions and lost messages

Dear forum,
I am developing an application in which messages should not get lost.
I have the following test setup :
an MDB which is deployed with the transaction attribute="NotSupported".
The MDB runs in a oc4j container.
The onMessage method of the bean is run in the Eclipse debugger.
I observe the following:
When the MDB picks a message from an AQ queue and enters the onMessage method the message state in the queue goes to "processed".
When the container is forced to crash before the onMessage method returns the message has disappeared from the queue and is not in the exception queue.
When I run the same test with the transaction attribute="Required". The onMessage method runs in a container managed transaction and the message goes to the exception queue with state "expired".
For various reasons I do not want to use CMT. But I do not want any messages to get lost.
Could someone please tell me if my observations are correct en what alternative options do I have?
Greetings,
Huub

No real help from me I'm afraid but just had a call from my brother who was just lost all his mail setting and messages, mail is appears as if it was started for the first time. His Mail folders in the Library have his pop and mac account folders but no contents.
Have you checked if the messages are in your library? (Home > Library > Mail)

Relation between TPMonitor and Weblogic

Hi all,
For example , take an application developed using 2 different
technologies.Say one is using an application server like weblogic and
the other is developed on Tuxedo.One of the main services that are
provided by TPMonitors like Tuxedo is to manage distributed
transactions.Same are managed by TransactionManager in weblogic.Are
these technologies completely replacable for one another ?
Thankx for your time...
-- mahati.

Mahati,
The way that I would describe it is that Tuxedo and WebLogic are both
application servers. It's just that when Tuxedo was first released, the word
application server didn't exist.
You should use the Tuxedo app. server if you have skills in and wish to use the
C, COBOL or C++ programming languages to develop your application, wheras you
shoukd use WebLogic if you have java skills that you want to use.
If you have a rage team with a mized skill-set, you can use both WebLogic and
Tuxedo and use the WebLogic Tuxedo connector to connect the 2 physical
environments to produce the effect of one logical application server.
Regards,
Peter.
Ravi Kumar Mahanti wrote:
Hi all,
For example , take an application developed using 2 different
technologies.Say one is using an application server like weblogic and
the other is developed on Tuxedo.One of the main services that are
provided by TPMonitors like Tuxedo is to manage distributed
transactions.Same are managed by TransactionManager in weblogic.Are
these technologies completely replacable for one another ?
Thankx for your time...
-- mahati.

Unable to create a JMS Message bridge between Weblogic 12c and Weblogic 8.1

Hi,
I am unable to successfully create a Message Bridge between Weblogic 12.1.1.0 and Weblogic 8.1. The error message being received is:
eis/jms/WLSConnectionFactoryJNDINoTX > ResourceAllocationException generated by resource adapter on call to ManagedConnectionFactory.createManagedConnection(): "javax.resource.ResourceException: ConnectionFactory: failed to get initial context (InitialContextFactory =weblogic.jndi.WLInitialContextFactory, url = t3://localhost:8001, user name = System) ">
The error on the monitoring tab is WARN: failed to connect to target.
Both domains are deployed on one box for testing purposes. The bridge itself is deployed on Weblogic 12c. The areas of config that may be of interest are:
<server>
<name>AdminServer</name>
<listen-address></listen-address>
</server>
<messaging-bridge>
<name>Bridge</name>
<target>AdminServer</target>
<source-destination>JMSBridgeSource12c</source-destination>
<target-destination>JMSBridgeTarget81</target-destination>
<selector>Test</selector>
<quality-of-service>Exactly-once</quality-of-service>
<qos-degradation-allowed>false</qos-degradation-allowed>
<durability-enabled>true</durability-enabled>
<idle-time-maximum>60</idle-time-maximum>
<async-enabled>true</async-enabled>
<started>true</started>
<preserve-msg-property>false</preserve-msg-property>
</messaging-bridge>
<app-deployment>
<name>jms-xa-adp</name>
<target>AdminServer</target>
<module-type>rar</module-type>
<source-path>D:\ORACLE~3\WLSERV~1.1\server\lib\jms-xa-adp.rar</source-path>
<security-dd-model>DDOnly</security-dd-model>
</app-deployment>
<jms-bridge-destination>
<name>JMSBridgeSource12c</name>
<adapter-jndi-name>eis.jms.WLSConnectionFactoryJNDIXA</adapter-jndi-name>
<user-name>System</user-name>
<user-password-encrypted>{AES}nfFzhs+0J/O2Cenf0g4zDsDyvIKENMF7cZ5sAVUehX0=</user-password-encrypted>
<classpath></classpath>
<connection-factory-jndi-name>JMSConnectionFactory12c</connection-factory-jndi-name>
<connection-url>t3://localhost:7001</connection-url>
<destination-jndi-name>JMSQueue12c</destination-jndi-name>
</jms-bridge-destination>
<jms-bridge-destination>
<name>JMSBridgeTarget81</name>
<adapter-jndi-name>eis.jms.WLSConnectionFactoryJNDIXA</adapter-jndi-name>
<user-name>System</user-name>
<user-password-encrypted>{AES}eBkO46cHvtrzEraOMIOdXow6WvEAtA4NCUDTQ4mC+9w=</user-password-encrypted>
<classpath></classpath>
<connection-factory-jndi-name>JMSConnectionFactory81</connection-factory-jndi-name>
<connection-url>t3://localhost:8001</connection-url>
<destination-jndi-name>JMSQueue81</destination-jndi-name>
</jms-bridge-destination>
I have enforced global trust between the two domains. I have disabled the guest user on the 8.1 domain but can’t see where to do this on 12c.
Any suggestions would be much appreciated.
Regards
John
Edited by: 958336 on 13-Sep-2012 03:11

Thanks for the recommendation. Unfortunately it did not help solve the problem.
I have managed to get a JMS bridge working between 12c and 8.1 by including the 8.1 weblogic.jar on the classpath. This setup was using eis.jms.WLSConnectionFactoryJNDINoTX.
After trying to use the adapter that supports transactions, WLSConnectionFactoryJNDIXA I received the following error:
java.lang.IllegalStateException: can only be called from server
Is this because the Weblogic 12c server now views the 8.1 server as being foreign?

Transaction support? Can i coordinate EJB transactions and COM+ transactions?

Can I call a transactional com object within an ejb transaction and have
success/rollback handled correctly? Or will I have to hand-code this? Are
any examples available?
Niels Harremoës
PricewaterhouseCoopers

WebLogic jCOM does not support coordination of transactions over COM+. There
are no examples of manual transaction coordination in the WebLogic jCOM
examples, and at present BEA has no plans to create one.
Chris Hopper
BEA Systems, Inc.
"Niels Ull Harremoës" <[email protected]> wrote in news:3bcc91f4
@newsgroups.bea.com:
Can I call a transactional com object within an ejb transaction and have
success/rollback handled correctly? Or will I have to hand-code this? Are
any examples available?
Niels Harremoës
PricewaterhouseCoopers

Transaction and Weblogic MDB

Similar Messages

Maybe you are looking for