Gary Bridge

Greenhorn
+ Follow
since Jan 20, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Gary Bridge

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