Important Notice: Our web hosting provider recently started charging us for additional visits, which was unexpected. In response, we're seeking donations. Depending on the situation, we may explore different monetization options for our Community and Expert Contributors. It's crucial to provide more returns for their expertise and offer more Expert Validated Answers or AI Validated Answers. Learn more about our hosting issue here.

If a distributed transaction involves JMS and JDBC, how do I ensure that the JDBC update is available when the JMS message is processed?

0
Posted

If a distributed transaction involves JMS and JDBC, how do I ensure that the JDBC update is available when the JMS message is processed?

0

The problem is that an application can receive the JMS message from the destination before the associated JDBC data is in the database. Distributed transactions guarantee all involved changes will either succeed or fail as a unit, but cannot guarantee that they will happen exactly simultaneously (the transaction manager instructs all resource managers to commit but cannot control the timing of the completion of that operation). For the WebLogic transaction manager, if the JDBC connection pool and the JMS server are both on the same server, and the transaction starts on the same server, the changes are committed in the order in which they were asked for by the transaction. This is not supported behavior, it just happens to be the current behavior. So if you can co-locate JMS and the JDBC connection pool, then you may have a chance. You could send the JMS message with a delayed birth-time, and hope that this is good enough.

0

A. The problem is that an application can receive the JMS message from the destination before the associated JDBC data is in the database. Distributed transactions guarantee all involved changes will either succeed or fail as a unit, but cannot guarantee that they will happen exactly simultaneously (the transaction manager instructs all resource managers to commit but cannot control the timing of the completion of that operation). For the WebLogic transaction manager, if the JDBC connection pool and the JMS server are both on the same server, and the transaction starts on the same server, the changes are committed in the order in which they were asked for by the transaction. This is not supported behavior, it just happens to be the current behavior. So if you can co-locate JMS and the JDBC connection pool, then you may have a chance. You could send the JMS message with a delayed birth-time, and hope that this is good enough. If the receiver fails to find the associated JDBC record, it

Related Questions

What is your question?

*Sadly, we had to bring back ads too. Hopefully more targeted.