• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

XA, JMS and a distributed database/CGI update

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
reply
    Bookmark Topic Watch Topic
  • New Topic