| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| 2 phase commit |
« View previous topic :: View next topic » |
| Author |
Message
|
| bigdavem |
 Posted: Sun May 12, 2002 5:08 pm Post subject: 2 phase commit |
 |
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
I'm trying to design a solution for a new client system we're developing where all inter-application communication is restricted to MQSeries. I'm not sure if it's possible, but I'd appreciate any ideas. I've already ploughed through the relevant redbooks and manuals....
Anyway, here's the scenario:
We have an application running on HP-UX with MQ Server installed. This application accepts client address details, and sends them via MQ to a second application running on a second HP-UX box, also with MQ Server installed. The second application updates its local (Oracle) database and sends a reply. At this point the first application also updates its own local (Oracle) database. We need to guarantee both databases are in sync, so if for any reason either of the updates fails, we want to be able to roll back both databases.
So basically we're trying to implement a 2 phase commit on databases on separate machines using only MQ. I'm aware that we could use Oracle to do it, but that's been deemed unsatisfactory from a design point of view (I know it's standard practice, but standard practice is never as much fun....).
Any ideas? |
|
| Back to top |
|
 |
| kolban |
| Posted: Sun May 12, 2002 6:53 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
My best advice is not to even start going down this road if you need true, real-time, consitency between the databases. MQSeries, like all message oriented middleware, agrees to reliably deliver the data from one machine to another. It does not assure when this will happen, only that it will. There is no two phase commit between separate queue managers. Don't even try going there.
If you need coordinated updates between different databases, then choose a transaction manager and perform the updates in the same application coordinated by the single transaction manager. This could be an EJB container, CICS, Tuxedo, Encina ... or a single MQ queue manager. |
|
| Back to top |
|
|
| bduncan |
| Posted: Sun May 12, 2002 9:19 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Kolban's right. I actually implemented such a system at a previous company. We had 20 application servers and 8 database servers. Any application server could cause an update on any of the databases. The other seven databases would then be kept in sync by sending MQSeries messages to each of them, via a third queue manager, an update controller, if you will.
Anyways, we ran into all sorts of complications, because if you can imagine, if the update succeeds on 7 of the 8 databases, but one fails, what do you do? Rollback all the updates? No, that's too inefficient. So we would then have the controller automatically take the misbehaving queue manager offline, so that messages would no longer be routed to it (we were using clustering). But then depending on why the update failed, bringing the database back online may require human intervention. Plus, we were doing so many updates through the system, that if any one of the databases remained offline for several hours, queues on the controller machine (flooded with updates destined for the offline database) would eventually fill up (to 640,000 messages) and then our whole system was in trouble.
In the end, we learned that it was better to just use the built in clustering support of Oracle. We had developed a working system with just MQSeries, but all too often, it would require human intervention when things went wrong.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| bigdavem |
| Posted: Mon May 13, 2002 3:10 pm Post subject: |
|
|
Acolyte
Joined: 16 Sep 2001
Posts: 69
Location: Sydney, Australia
|
| Thanks for that guys, that's what I suspected. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
