views:

558

answers:

2

Well, actually JBoss does send the message, but only when the current transaction started by the EJB is finished.

We have this problem with JBoss 4.0.3 and Spring's JmsTemplate. An EJB sends a message to a queue with a temporary queue as the reply_to field. Then, inside the same transaction, we listen for the response given by the first MDB. The problem is that the JmsTemplate's method "send" isn't executed after the transaction have finished. So, by the time the message is sent to the queue, and processed by the MDB, the listener of the temporary queue is gone.

This is called "Synchronous Reception"

Two things change this behavior but does raise some concerns:

  1. Change the EJB's transaction type to BMT. (Concern: BMT sucks)

  2. Create a thread that all it does is to call the JmsTemplate.send() method.

As a side note, this is an EJB that is working correctly on a weblogic environment, and the message does get sent when it should, in the middle of the transaction not when it's over.

Thanks for any help.

+1  A: 

JBoss's behaviour is correct. JMS is a transactional API, and sends should only be executed when the tx commits.

It may be possible to convince JmsTemplate not use the current transactional context, although it makes a point of trying to hide the unpleasantness of the JMS API from you.

skaffman
"and sends should only be executed when the tx commits"But this disallows any possible use of synchronous receptions.
Ubersoldat
Within the context of a transaction, yes. But if you can persuade JmsTemplate to execute outside of that context, then you should be OK. Alternatively, don't use JMSTemplate - it's just a wrapper around the JMS API.
skaffman
I'm marking your answer as _the_ one since it got me in the right direction. To not use the current transaction context I used my second option described in the question.
Ubersoldat
A: 

You could wrap the JMS template in code, either a Stateless session bean or a service method using Spring's transaction management, that uses a transaction propagation of REQUIRES_NEW. That way the sending of the message is in its own transaction that will commit the sending of the message outside the scope of the wrapping transaction.

I'm not sure why this would work on Weblogic though. My guess would be that on Weblogic it's not recognizing the queue as an XA Queue.

Jason Gritman
Thanks Jason, I'll take a look at this solution and see if things work as expected.
Ubersoldat