If I set the factory as XA enabled, when does the message become available? Right after the session.commit() or when the MDB exits (and Weblogic does the commit)?
Main Topics
Browse All TopicsFrom within a transactional MDB I need to send a message on a JMS queue. I want this to be transactional, meaning that if the MDB gets an error, the message will never be sent. I also want to make sure that me DB updates are committed before any receiver has a chance to see the message
I set the session to be transacted, but I still think I see that messages are delivered before the DB commits.
Do I need to set "XA Connection Factory Enabled" on the queue connection factory?
Looking at the code below, I see that I explicitly call commit(). That might be my problem, but if I do not call commit(), will Weblogic do the commit for me when the MDB finishes?
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
We tried to set the connection factory as XA, but the message still goes out before the transaction commits.
From http://download-llnw.oracl
A JMS transacted session supports transactions that are located within the session. A JMS transacted sessions transaction will not have any effects outside of the session. For example, rolling back a session will roll back all sends and receives on that session, but will not roll back any database updates. JTA user transactions are ignored by JMS transacted sessions.
One more thing I observed was this..
queueConnection = queueConnectionFactory.cre
Shouldn't it be like the following to inform weblogic that, the session you are creating is transaction aware.
queueConnection = queueConnectionFactory.cre
Are you sure, it was entering the commit() if-loop earlier?
Ok, I went through the question again in more detail. Looks like you are having some MDB and performing some additional operations on that MDB. If you get an error, the queue shouldn't be sent a message (short explanation).
1. Let us roll back your XA setting in connection factory.
2. JMS transactions are possible in 3 different ways. One of them is to use MDB and you have chosen it.
3. If you want your MDB to participate in transaction, you need to make some changes in your deployment descriptor.
http://download-llnw.oracl
>>>
To configure container-level transaction management:
Set the transaction-type element in the message-driven element in the ejb-jar.xml file to Container.
Set the trans-attribute element in the container-transaction element in ejb-jar.xml to Required.
Note: If transaction-type is set to Container, and trans-attribute is not set, the default transaction-attribute value (NotSupported for MDBs) is applied. WebLogic Server allows you to deploy the MDB, and logs a compliance error. However, if you make this configuration error, the MDB will not run transactionallyif a failure occurs mid-transaction, updates that occurred prior to the failure will not be rolled back.
So I guess you have missed to change trans-attribute and transaction-type in your descriptors. I would suggest you to apply this change in your descriptor and redeploy it. It would be good if you could check for any errors in weblogic console and post it here.
We already deployed the MDB as a transactional bean. It has been that way for a while.
We just need to include the message sending in the transaction,
We found the following
http://download.oracle.com
Essentially, we need to set useTransactedSession to false and use an XA queue connection factory. This lets Weblogic manage the transactions for the queue instead of the session.
This appears to work.
Here is an excerpt from that site:
Sending a JMS Message In a J2EE Container
After you declare the JMS connection factory and destination resources in the deployment descriptors so that they are mapped to the java:comp/env JNDI tree, you can use them to send and/or receive JMS messages inside an EJB or a servlet.
For example, the following code fragment sends a message:
InitialContext ic = new InitialContext();
QueueConnectionFactory qcf =
(QueueConnectionFactory)ic
Queue destQueue =
(Queue)ic.lookup("java:com
ic.close();
QueueConnection connection = qcf.createQueueConnection(
try {
QueueSession session = connection.createQueueSess
QueueSender sender = session.createSender(destQ
TextMessage msg = session.createTextMessage(
sender.send(msg);
} finally {
connection.close();
}
Also, none of the transactional XA extensions to the JMS API are used in this code fragment. Instead, the container uses them internally if the JMS code is used inside a transaction context. But whether XA is used internally, the user-written code is the same, and does not use any JMS XA classes. This is what is specified by J2EE. Writing EJB code in this way enables you to run EJBs in an environment where transactions are present or in a non-transactional environment, just by changing the deployment descriptors.
Business Accounts
Answer for Membership
by: rajesh_balaPosted on 2009-09-02 at 08:03:24ID: 25241788
You need to set the connection factory setting as XA enabled.