| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| JDBC Adapter Transaction Coordination |
« View previous topic :: View next topic » |
| Author |
Message
|
| fitzcaraldo |
 Posted: Thu Oct 06, 2005 6:11 pm Post subject: JDBC Adapter Transaction Coordination |
 |
|
Voyager
Joined: 05 May 2003
Posts: 98
|
We are looking at using the JDBC Adapter with the Message Broker and I have a question around transaction coordination.
Can anyone tell me if it's possible to coordinate the database operation with the WMQ operation in a single unit of work? |
|
| Back to top |
|
 |
| RocknRambo |
| Posted: Sat Oct 08, 2005 7:23 am Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
WBI Adapters with MB as the Broker work with MQ's, so when u say Unit Of Work.. are you looking with Message Flow??
If so, the answer is NO, If the adapter is down and message flow running, the messages pile up in the Request queue.
Was this ur question!!!!
-RR |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 08, 2005 10:01 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| RocknRambo wrote: |
| Was this ur question!!!! |
I don't believe that was his question (what's with the exclamation marks?), he was inquiring whether the JDBC adapter employs a transaction between the events table and MQ, commiting them both using some XA manager. For example, the JDBC adapter finds a new event, deletes it from table and MQPUTs a message to the broker - whether these two operations are commited together.
Since I cannot find any reference to this in the manuals, infocenter or redbooks, I think that this is impossible, and is by all appearances not the default; If I were you, I'd contact IBM about this.
One odd way to find out is to JAD the adapter code and go over it, which, considering the state of IBM support for this product, may be faster than going through the usual channels.
Maybe someone else here has a better answer, but in any event, don't forget to let us know what you find out  |
|
| Back to top |
|
|
| fitzcaraldo |
| Posted: Sat Oct 08, 2005 10:48 pm Post subject: |
|
|
Voyager
Joined: 05 May 2003
Posts: 98
|
Thanks for that.
The lack of mention of this the doco would also indicate that there is no transaction coordination. This means we have to chose the possbility of either two operations or none in the event of a failure part way through a transaction. |
|
| Back to top |
|
|
| hopsala |
| Posted: Sat Oct 08, 2005 11:37 pm Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| fitzcaraldo wrote: |
| The lack of mention of this the doco would also indicate that there is no transaction coordination. This means we have to chose the possbility of either two operations or none in the event of a failure part way through a transaction. |
You won't have a choice - when working without some XA mechanism or other, it is not up to the user to decide, it is decided for him by the way the application code (here, the adapter code) is written.
If the order is: , DBCMIT MQCMIT and the adapter crashes immediately after the dbcmit, you'll simply lose data and there's not way of telling it; If the order is MQCMIT DBCMIT, the same scenario will cause duplicates the next time the adapter goes up. My point is, it's not up to you, and it's undetectable. (this description applies for event processing only)
Do not confuse in-doubt messages, which arise when the application crashes *within* the MQCMIT/DBCMIT, and what I just described - these are two seperate things, albeit related. |
|
| Back to top |
|
|
| vk |
| Posted: Thu Oct 13, 2005 8:13 am Post subject: |
|
|
Partisan
Joined: 20 Sep 2005
Posts: 302
Location: Houston
|
Hi,
This is my understanding regarding the functioning of JDBC adapters. Can anyone tell me if this is correct?
During Event notification (At the source side) -
1. When the Queue Manager goes down while the connector is processing an event, then the connector terminates and the event remains in the event table. When the Queue Manager comes up, the connector can be restarted and the event will be processed again.
2. When the database crashes while the connector is processing an event, the connector terminates. The event is not sent to the broker and it remains in the event table. So when the database is up and the connector is started, the event will be processed again.
During Request processing (At the destination side) -
1. If the Queue Manager goes down, while the connector is processing a request, the connector terminates. The record is not inserted into the database. The request remains in the Request Queue and will be processed again when the connector and Queue Manager are up.
2. If the database crashes while the connector is processing a request, the connector terminates. The record is not inserted into the database and will be in the Request Queue since MQCMIT has not happened. So when the database and connector comes up, the request will be processed.
Thanks,
VK. |
|
| Back to top |
|
|
| RocknRambo |
| Posted: Thu Oct 13, 2005 1:30 pm Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
hopsala wrote:
| Quote: |
| I don't believe that was his question (what's with the exclamation marks?), he was inquiring whether the JDBC adapter employs a transaction between the events table and MQ, commiting them both using some XA manager. For example, the JDBC adapter finds a new event, deletes it from table and MQPUTs a message to the broker - whether these two operations are commited together. |
The JDBC adapter uses one thread for polling the events from the eventstable. its one unit of work till it delivers to the DeliveryQueue. the event status relates the same, event_status = 0 - ready to process, 3 - InProcess, 1 - processed.
till the status changes to 1, the transaction is complete. and if the adapter dies for some reason in the status of 3, the event is not picked up (Not Delivered to MQ) and in the next restart, the adapter changes to 0.
hopes this helps
-RR |
|
| 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
|
|
|
|
