how to force DB update before sending the JMS message to next queue

Question

I have a simple usecase in a Java JMS configuration on Weblogic 11g container (using Spring 3.x framework for Dependency injection, and EJB 2.x for MDBs and declarative transaction management in ejb-jar.xml).

1. Read message from a queue-1
2. Unmarshall the message into java object
3. save the unmarshalled java object into a database table
4. send the message (containing object-id from step_3) to the next queue-2
5. read the message on queue-2 ( and load the object from database based on its object-id)

My problem is in a lot of cases, on step-5, I find the object-id doesn't exist in the database yet, I throw exception, message loops back and gets re-tried, eventually the object_id shows up in the database and the message on step-5 gets processed successfully.

The workflow covering step 1-4 (implemented in an MDB) has a transaction demarcation done as "REQUIRED" in ejb-jar.xml and the connection factory is XA enabled. That means the workflow (step1-4) has to run in a transaction that gets committed when the message is eventually sent to queue-2 in step4.

Then why does step-5 not find the object-id in the database in a lot of cases. Is there any way I can force this to avoid or reduce the getting this error in step-5.

Answer 1

If you say that in a lot of cases, on step 5, the object is not in the db, quite possibly that the transaction does not get committed by the time you get to step 5.

What if you wait for the result from the transaction, before you read the message from queue 2. If these are 2 different processes, you can notify the other machine that all the messages in queue 1 have been delivered and it is ready to proceed by reading message from queue 2.

Answer 2

I was looking for a solution using weblogic container. I found this setting called " Time-to-Deliver Override" in weblogic console - which is defined as The default delay, between when a message is produced and when it is made visible on its target destination, regardless of the delivery time specified by the producer and/or connection factory

time-to-deliver-override-link I set this value to 3-4 seconds and I got this issue reduced by 90% of the time.

Just pasting this information here so that someone else looking for this issue can benefit from it.