2

I think I am not getting something right with JMS and JTA. I am running in a Java EE container with all CMTs. Here is what I am doing:

  1. In an SLSB, write something to the database
  2. From the same method of the SLSB, post a message to a JMS queue
  3. An MDB in the same container listens to the JMS queue and picks up the message
  4. The MDB reads the database

The problem is, the MDB does not see the changes made to the database in step 1.

I verified that steps 1 and 2 happen inside a single XA transaction, as expected. My expectation is that a second XA transaction would start at step 3, after the first XA has been committed. But it seems that the MDB receives the message before the XA transaction that posted the message has been committed.

Is my expectation wrong and what I am seeing is normal?

I am running under JBoss 6. The SLSB is local. Both the SLSB and the MDB are in the same application.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
Masum
  • 61
  • 1
  • 6
  • Could you specify why you are doing this? Does your db support firing events when it changes a table, you could make it fire off a http request to your application, stating the table name, action (insert,update etc) and id, then your app listens to it, and does its thing. – rapadura Aug 15 '11 at 06:50
  • 2
    I would generally expect that the MDB would not fire until the transaction in steps (1+2) commits, as until that point the message should be 'locked' in the transaction and not generally visible until commit (there are sometimes provider-specific caveats here though). It's hard to say for sure with the information given, but if step 2 isn't being done within a transaction it would explain what you see - although I know that you say you have verified steps 1+2 are atomic, is there any chance this is not correct? – strmqm Aug 15 '11 at 07:49
  • @Antonio That would make it overly complicated and closely tied with the DB vendor. I already use loads of JMS and it makes more sense in this project to leverage JMS more. – Masum Aug 15 '11 at 16:11
  • @strmqm That's my thought too. I will test more carefully to make sure that steps 1+2 are indeed being done inside an XA transaction. – Masum Aug 15 '11 at 16:14

2 Answers2

4

I found the problem! My JMS connection factory was not XA aware. I had looked up /XAConnectionFactory for my JMS connection factory. In spite of the name, that's the wrong resource to lookup for a regular app in JBoss. There is a java:/XAConnectionFactory too, which does not work either. The correct resource name is java:/JmsXA. I used it and everything is working just as expected.

Thanks to @strmqm for nudging me to the right direction.

Masum
  • 61
  • 1
  • 6
1

I saw a conceptually similar problem in an app built w/ WebLogic 7. The DB commit from tx1 wasn't complete by the time that tx2 (initiated by a JMS send in tx1) tried to read it.

The trouble there was that our configuration involved a WLS 7 XA emulation layer with a non-XA db connection (to Oracle DB). This risk was part of that XA shortcut. Apparently if we'd gone w/ the true XA all the way to the DB, that hole would have closed. Never ended up testing that.

You say this is JBoss. Any chance that they've got some similar shim that bypasses the XA and gives this same surprising result?

John M
  • 13,053
  • 3
  • 27
  • 26