| Author |
Message
|
| vivekkooks |
 Posted: Thu Jul 03, 2003 4:30 am Post subject: committing and backing out units of work |
 |
|
Voyager
Joined: 11 Jun 2003
Posts: 91
|
Hello,
I have installed MQseries on Linux/Intel.
How can I use the committing and backing out mechanism in the following test case.
I need to transfer the data from db1(eg oracle) to db2(DB2). I will be using mqseries to transfer the data. MQSeries Clients(C1 and C2) are installed on db1 and db2 systems(Linux/Intel). MQManager is installed on a different system(Linux/Intel).
db1+C1 ( installed on linux/intel)
|
|
|
MQServer(MQManager) (installed on Linux/intel)
|
|
|
db2+C2 (installed on linux/intel)
1.C1 reads the data from db1, it puts the data in mqseries. C2 gets the data(message) from mqseries. both operations are asynchronous.
2. So shall i use local unit of work(MQPUT followed by MQCMIT/MQBACK by C1 and MQGET and MQCMIT/MQBACK by C2) or global unit of work?
3. is there any sample code which shows local and global unit of work?
thanks
vivek[/img] |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Thu Jul 03, 2003 7:25 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
Go out to:
http://www.developer.ibm.com/tech/sampmq.html
and check out mqsync.*, mqadhoc.c, mqdb2.sqc, mqdb2log.java. They are programs that use MQ and DB2 to perform units of work. They might help some.
In your scenario, it doesn't look like you make any DB updates. This being the case, I'd go with the single phase commit of the MQ messages. |
|
| Back to top |
|
|
| bduncan |
| Posted: Thu Jul 03, 2003 5:00 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Also you can look in the software repository on this site (under the "repository" menu item in the nav bar above) and there are several sample programs that fit your needs...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| vivekkooks |
| Posted: Mon Jul 07, 2003 12:10 am Post subject: |
|
|
Voyager
Joined: 11 Jun 2003
Posts: 91
|
In my scenario, I am making the DB update on C2. i.e. Retrieve the data from database(db1). C1 will put the message. C2 will retrieve the message and will update the db2 database.
In this scenario should I use single phase commit as follows:
C1(MQSeries Client app):
1. get the data from database.
2. form a message.
3. put the message and if successful commit the transaction.
C2(MQSeries Client app)
1. retrieve the message.
2. update the db2.
3. if the update is successful then MQCMIT else rollback.
or should I use two phase commit as follows:
C1(MQSeries Client app):
1. MQBEGIN
2. get the data from database.
3. form a message.
4. put the message and if successful commit the transaction.
C2(MQSeries Client app)
2. MQBEGIN
1. retrieve the message.
2. update the db2.
3. if the update is successful then MQCMIT else rollback.
In two phase commit, The only difference is use of MQBEGIN, rest of the code is the same.
Can you please suggest either to use single phase commit or two phase commit in this scenario.?. Please correct me if the pseudo code is wrong... |
|
| Back to top |
|
|
| vivekkooks |
| Posted: Mon Jul 07, 2003 3:15 am Post subject: |
|
|
Voyager
Joined: 11 Jun 2003
Posts: 91
|
Also,
If the message is retrieved by C2(Mq Series Client), it performed the database updations on db2 and made commit on the database transaction.
But it may hapen that C2 crashes before committing to MQ Series.(ie commit should happen on MQSeries, in this case )
So, How to avoid this problem?. Is there any way to handle such problem.?
MQ Series Application program Guide says the following thing:
(A two-phase commit process is one in which updates that a program has
made to WebSphere MQ queues can be coordinated with updates to other
resources (for example, databases under the control of DB2®). Under such a process, updates to all resources are committed or backed out together.)
But i am unable to understand how to do this programatically. There may be multiple resources(eg. db1 in my case as Oracle and db2 in my case as DB2).
thanks, |
|
| Back to top |
|
|
| bower5932 |
| Posted: Mon Jul 07, 2003 8:54 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
From what I see, it looks like you need a single-phase commit to read your database and put the MQ message. Since you are doing a DB read, you won't lose any data. (How do you know what to read?)
The second piece of work is the two-phase commit. You want to make sure that both the MQ message gets read and the DB update take place in the same unit of work. If something goes wrong (in the XA under the covers), you'll get notified of in-doubt transactions at restart and you'll have to decide how to resolve them. |
|
| Back to top |
|
|
| vivekkooks |
| Posted: Mon Jul 07, 2003 10:07 pm Post subject: |
|
|
Voyager
Joined: 11 Jun 2003
Posts: 91
|
Hello,
The MQ Series documentation says, It doesnot have transaction support for Oracle and Sybase on Linux.It only supports DB2.
Table 11. XA-compliant relational databases
MQSeries product............... DB2...........Oracle.................Sybase
MQSeries for AIX ................Yes............Yes......................Yes
MQSeries for HP-UX..............Yes............Yes..................... No
MQSeries for Linux................Yes............No..................... No
MQSeries for Sun Solaris........Yes...........Yes......................Yes
MQSeries for Windows NT
and
Windows 2000
......... Yes............. Yes...................Yes
So, How to use Two Phase Commit Mechanism for these databases(Oracle and Sybase) on Linux?. |
|
| Back to top |
|
|
| jhalstead |
| Posted: Tue Jul 08, 2003 12:51 am Post subject: |
|
|
Master
Joined: 16 Aug 2001
Posts: 258
Location: London
|
Without XA capabilities you could build some degree of integrity in to your application. Perhaps using another queue as a work in progress area.
For instance you could get from source queue, put a new message on the wip queue containing useful information for recovery - maybe the original message.
Get from source queue
Put useful data to wip queue
commit
perform DB updates and commit
get from wip queue
commit
If anything goes badly wrong in the processing it's likely that your app will shut down. When it starts up again it could go to the wip queue and use the data to determine if the db updates are complete.
This is all very closely linked in to the db data that is held and what useful field are available to query. Obviously if you are able to be a bit invasive with the db then this gets easier!
You could also create a wip table in the db, this would store the mqmd.msgid and this insert would be commited along with the "real" db updates. Now you can easily work out where you are at after either a db, mq or hw failure!
Anyway - just a few thoughts
Jamie |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jul 08, 2003 5:43 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It would likely be easier and faster, if one has to reinvent XA, to browse the original message and then later do a destructive read, instead of doing two destructive reads and one persistant put. Although this way you can't necessarily use the backout count for retry management.  |
|
| Back to top |
|
|
|
|
