MDB starts before Queue send is commited

I have the following problem: In a SLSB I send a message to a JMS queue. I need the JMSMessageID from the message to create a EntityBean which I also do in the same SLSB and within the same transaction.

The MDB that gets started with this message now changes a state of exactly this EntityBean, but my problem is, that the MDB already gets started before my SLSB tries to create the EntityBean, so I get a ObjectNotFoundExeption while trying to update the EntityBean.

I expect the WLS Container to wait until the SLSB transaction (attribute Required) is commited. Do I have to set a flag anywhere to do this or is this behaviour normal?

Did you specify the transaction behaviour of your JMS-Session as "transacted"? (Argument true)?

Stephan Staeheli
Greenhorn

Joined: Jul 22, 2002
Posts: 27

posted Oct 13, 2004 00:12:00

0

Originally posted by Severin St�ckli: How do you get your QueueConnectionFactory / Queue? Through the container, I guess?

Yes, I did.

Originally posted by Severin St�ckli: Did you specify the transaction behaviour of your JMS-Session as "transacted"? (Argument true)?

No, I have false and CLIENT_ACKNOWLEDGE as parameters.

I have changed my JMS definition that the Connection Factory is XA-enabled. I also activated a flag that my JDBC Data Sources emulates a 2-phase commit. Now I works as I expected it.

I thought XA is only necessary when you have transaction running on more than one application server? Am I wrong?

Regards, Stephan

Severin Stoeckli
Ranch Hand

Joined: Jul 21, 2004
Posts: 62

posted Oct 13, 2004 14:25:00

0

Hi Stephan (chasch d��tsch? ;-)

I thought XA is only necessary when you have transaction running on more than one application server? Am I wrong?

Yes, you're wrong. As soon as you have one single transaction distributed over two different data sources, you need XA. How else can the container assure that the Transaction (for datasource DB and for datasource MDB) is committed at the "same" time?

Question: which attributes did you set? The correct settings for your problem are (in my opinion):

When you create a session in an enterprise bean, the container ignores the arguments you specify, because it manages all transactional properties for enterprise beans. It is still a good idea to specify arguments of true and 0 to the createSession method to make this situation clear:

session = connection.createSession(true, 0);

When you use container-managed transactions, you usually specify the Required transaction attribute for your enterprise bean's business methods.