| Author |
Message
|
| scar |
 Posted: Tue Feb 01, 2005 3:34 pm Post subject: About Commit and rollback |
 |
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
HI
My application puts a message to a queue, from there i need to update a database.
I had atriggered application running on that queue, so that it gets the message and updates the database.
There is no error handling at all.
once I get the message from the Q and if the db is down , or if an exception is thrown because of any thing the message is lost.
I have read somthing about commit and rollback, but I dont know how to implement.
what happens to the message when roll back occurs.
does it go back to the same Q.
If so will it trigger the application again.
Thanks |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Feb 01, 2005 8:32 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What environment are you programming in.
Where is your MQ server ?
We need more details on the scenario....
Are we talking about JMS ?? |
|
| Back to top |
|
|
| scar |
| Posted: Wed Feb 02, 2005 3:30 am Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
Its UPES implementation.
WorkFlow puts a message to a queue on FMCQM.
Work Flow is on AIX.
From the q a triggered application gets the message parses the required information and updates db2.
Trigger type is every.
my concern is what if the db is down.(the message will be lost) |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Feb 02, 2005 7:11 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
You didn't mention the language you are using. It sounds like you need to do a two-phase commit with the Qmgr and database. You'll use the syncpoint option to get your message and make your database update. If the database update fails, you rollback and your message stays on the queue. You'll probably need to add some logic into your program to handle the fact that you don't want to retry forever or immediately (ie, a backout queue). There is a small sample that does this at:
http://www.developer.ibm.com/tech/sampmq.html
Look for mqdb2.sqc or mqdb2log.java. |
|
| Back to top |
|
|
| scar |
| Posted: Wed Feb 02, 2005 7:30 am Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
so if the message is backed out then again it triggers the application(an infinite loop until the exception is gone).
is there any parameter that says if backed out put to a BACKUP q
(if we specify the BOQNAME on the q --- The qmgr doesnt do any thing)
or should it be done through API(MQPUT).
I am using JAVA |
|
| Back to top |
|
|
| EddieA |
| Posted: Wed Feb 02, 2005 8:13 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
| Quote: |
| is there any parameter that says if backed out put to a BACKUP q |
No. You would have to write that logic into your application, by checking the Backout Count.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 02, 2005 8:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, you should not use Trigger Type = Every.
It is not guaranteed to trigger on every new message.
You should trigger on FIRST, process all messages until the queue is empty, and then stop.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Feb 02, 2005 8:39 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
| scar |
| Posted: Thu Feb 03, 2005 3:23 am Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
| Quote: |
| Also, you should not use Trigger Type = Every. |
But its a synchronous process.
as soon as the message is put Q it should be processed and response should be sent back.
Also there might not be more than 3 to 4 mesages in a day.
Is the any other way of doing it with out using TRIGGERTYPE = EVERY
Thanks |
|
| Back to top |
|
|
| nathanw |
| Posted: Thu Feb 03, 2005 3:38 am Post subject: |
|
|
Knight
Joined: 14 Jul 2004
Posts: 550
|
i am assuming that yu do not have WBI installed as you could do all this with a simple message flow as if the db was down it would send the message back to the beginning and try again until success or backout is reached
surely once the application takes the message it is outside the mq domain so to speak and in the hands of the application
why not write the application so that if the db is down it keeps the message and retries until succesful or returns the message to a queue for later usage |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 03, 2005 6:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| scar wrote: |
| Is the any other way of doing it with out using TRIGGERTYPE = EVERY |
Yes.
But the Trigger Type doesn't affect how often your program reads messages.
In fact, building your application the way I said will make it process messages FASTER. Here is why. With trigger type= EVERY and your program reading only one message at a time, then every message causes a new JVM to start, your program to load, and then a queue manager connection established, and the queue opened, the message got, the queue closed, the connection closed and the JVM ended. For each and every message.
If you do it the way I said, then the only time the JVM needs to be started, the queue manager connection established,and the queue opened is when the online application hasn't sent any messages for a bit.
You can also code your application to sit in a loop, with FAIL_ON_QUIESCE and with the MQ Get set to WAIT. Then the instant a message comes in, the GET will return from WAIT, and your program can process it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| scar |
| Posted: Mon Feb 07, 2005 1:52 pm Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
| Quote: |
| You can also code your application to sit in a loop, with FAIL_ON_QUIESCE and with the MQ Get set to WAIT |
I understood what you are saying, but i wasnt able to implement it using JAVA API.
If you have any Code snippet can you please post it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 07, 2005 2:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Post YOUR code snippet, and we will tell you what you are doing wrong.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| scar |
| Posted: Thu Feb 17, 2005 12:43 pm Post subject: |
|
|
Centurion
Joined: 23 Jun 2004
Posts: 145
|
| Quote: |
| Post YOUR code snippet, and we will tell you what you are doing wrong. |
This is how I coded it
Does it make any sense or is there a better way of doing it.
while( OutQueue.getCurrentDepth() != 0)
{
MQGetMessageOptions gmo = new MQGetMessageOptions() ;
gmo.options = MQC.MQGMO_WAIT + MQC.MQGMO_FAIL_IF_QUIESCING + MQC.MQGMO_CONVERT + MQC.MQMO_NONE + MQC.MQGMO_SYNCPOINT;
System.out.println("Get Message Options are Set" );
System.out.println("Current depth of the Q = "+ OutQueue.getCurrentDepth());
MQMessage outMessage = new MQMessage();
OutQueue.get(outMessage);
System.out.println ("outMessage");
System.out.println("outMessage.getMessageLength()="+outMessage.getMessageLength());
byte[] b = new byte[outMessage.getMessageLength()];
outMessage.readFully(b);
String replyMsg = new String(b);
System.out.println (" The message is \n" + replyMsg);
if(OutQueue.getCurrentDepth() == 0)
{
System.out.println("Wait Started");
wait(60000);
System.out.println("Wait Ended");
}
} |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Feb 17, 2005 12:52 pm Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
I wouldn't loop based on the current depth of the queue. Try looping on a 2033 (no message available). You could also make your get have a wait and remove your code to wait based on the current depth of the queue.
You want to avoid basing your program around the current depth. Messages that aren't committed show up in this count, and you'll probably face a load of problems in the future because of this. |
|
| Back to top |
|
|
|
|
