0

I have a message-driven bean which receives messages from a queue, processes them, and sends messages to another queue, with

onMessage(Message inputMessage) {
    ... Message processing stuff...
    Connection connection = connectionFactory.createConnection();
    Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
    Message outputMessage = session.createObjectMessage();
    outputMessage.setJMSCorrelationID(uniqueId);
    MessageProducer messageProducer = session.createProducer(outputQueue);
    messageProducer.send(outputMessage);
    ... Some more processing...
    QueueBrowser browser;
    browser = session.createBrowser(outputQueue, 
              String.format("JMSCorrelationID='%s'", uniqueId);
}

Then, I check the queue for the uniqueId, but the message does not yet appear in the queue. After experimenting a little, I found out that the message appear in the output queue only after the onMessage method has returned.

Is this a bug? Is there a way to send the outputMessage immediately, so that I can be sure that after messageProducer.send(outputMessage) the message does appear in the outputQueue?

Darshan Patel
  • 2,839
  • 2
  • 25
  • 38
user4052054
  • 395
  • 1
  • 6
  • 22

3 Answers3

2

Seems like the flip-side to the situation here - JMS rollback

You're wanting to avoid the transactional behavior -- send immediately unrelated to the MDB transaction.

Reading the JavaEE 7 Connection.createSession() docs it sounds like there's not a good way to create a session detached from the MDB's JTA transaction. The docs go so far as to say that @schtever's answer of using session.commit() won't work.

If all this is true, maybe create some additional method that does the JMS send call. Set this additional method as transaction NOT_SUPPORTED or maybe REQUIRES_NEW.

Community
  • 1
  • 1
John M
  • 13,053
  • 3
  • 27
  • 26
0

Issue a session.commit(); after the messageProducer.send(outputMessage);

schtever
  • 3,210
  • 16
  • 25
0

When running in an application server the JMS operations enlist in any global transaction. The solution to this is to do the send in another transactional context. The simplest thing to do is move the send into an EJB with a transaction attribute of requires new.

Alasdair
  • 3,071
  • 15
  • 20