Two Laptop Bag*
The moose likes EJB and other Java EE Technologies and the fly likes XA, JMS and a distributed database/CGI update Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "XA, JMS and a distributed database/CGI update" Watch "XA, JMS and a distributed database/CGI update" New topic
Author

XA, JMS and a distributed database/CGI update

Gary Bridge
Greenhorn

Joined: Jan 20, 2005
Posts: 1
Hi Y'all!

I have a situation where I need to update two different systems (on two different servers) in a single transaction.

One of the systems is straightforward Java and database, the other is a complex CGI-BIN app.

The two updates would preferably happen simultaneously but if the CGI-BIN system is down it will be OK to do it's update later (as long as it does get done).

The simple way to do this would just be to do the database update and then do the CGI update (via a Java Bean on the CGI server). Problem here is that if the CGI update fails we somehow have to roll back the first transaction or - re-try the CGI update - so I then get into building some messy code to do this.... it gets especially messy when you start considering what happens if either server crashes halfway through etc.

Anyway � I was thinking that perhaps I could use JMS as part of an XA transaction to make sure both updates happen.

i.e. I do my database update, then send a message to a JavaBean on the CGI server (via a queue on the main server). The JavaBean on receipt of the message would setup the environment variables for the CGI app and execute it.

These two updates (database+sending of the message) could be part of the same transaction so XA could roll one back if the other one failed.

The message to the JavaBean would of course be async and the main transaction would only wait until the message was confirmed as arriving at the queue (i.e. it wouldn�t wait for an acknowledgement from the Javabean). This is because it would consider that once the message was safely in the JMS queue it could rely on JMS to make sure that part of the transaction completed.

That way if the CGI server is down � the message would just stay in the queue and be redelivered at intervals until the JavaBean / CGI app was up and the update did go through.

Lost ??? Here�s a summary !

Start Transaction
Do database update
Send JMS message to JavaBean but only wait until queue confirms receipt
Commit
End Transaction

At some point in the future�.
Queue forwards message on to JavaBean (if it can�t it retries every 10min say),
JavaBean executes CGI app using the data in the JMS message.

So a few questions�..

1. Is this a sensible way to use JMS � effectively allowing legacy app updates to become part of a transaction by using persistent JMS as a robust re-try mechanism ???
2. Is a JavaBean the right thing to receive the message and execute the CGI script � I know it�s not going to be efficient � but will it work ???
3. I know XA supports database update and JMS in a single transaction � but does this mean that it will somehow roll back a JMS message if the database update fails and vice versa � roll back the database update if the sending of the message fails ?

Thanks in anticipation !
Gary
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: XA, JMS and a distributed database/CGI update
 
Similar Threads
Distributed transactions in EJB
Could any one tell me what's the benefit of Message Driven EJBs?
Seeking ideas for the design of a JTA/XA transaction test
MDBs and Transactions
Enthuware question doubt