A message flow can be considered to consist of the following constituent parts:
The sequence of events when a flow processes a message can be considered to be:
Note that this sequence of events makes no distinction between the accessing of tables and the writing of output messages. Although a flow is usually thought of as producing some sort of output message, there is no real distinction between this and updating a database table. In both cases there is some change to the state of the data in the system.
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
The line represents the data in the system as time passes. At time 1 a message arrives and is taken from the input queue. At times 2, 3, 4 and 5, database tables are updated or queues are written to. These changes of state are indicated by the x symbol. Finally at time 6 the output messages depart and the system quiesces. Between these events there is no change to the state of the data and this is indicated by the = symbol.
Now let us consider the effect of failures on the system. If a failure (e.g. the plug is pulled on the machine on which the broker is running), the changes to the state of tables and queues made prior to the failure will have taken place but those that should have occurred after will not take place at all. It is quite likely that such a situation is unacceptable (e.g. a payment from my current account to my mortgage account has been taken from the current account table but not added to the mortgage account table).
=====x=========x===x=======x=============x====x===== 1 2 3 4 5 6
The line represents the extra data in the system as time passes. At time 1 a message arrives and is taken from the input queue. Before this there is no extra data in the system and this is indicated by the - symbol. After this time, the state represents the fact that a message has been taken from the queue so that, if need be, it can be put back. At times 2, 3, 4 and 5database tables are updated or queues are written to. Again the state of the extra data changes so that the changes to tables and queues can be undone if need be. Finally at time 6 the output messages depart, the system quiesces and there is no extra data in the system once more. Between these events there is no change to the state of the extra data and this is indicated by the symbol =. If a failure occurs at any time between 1and 6 the extra data is used to restore the original state of the system's data so that, in effect, none of the output queues have been written to, none of the tables have been changed and the input message hasn't been taken from the input queue. If no failure occurs the changes become permanent at time 6, that is, an undo operation following a subsequent failure will not undo them.
This mode of operation is known as coordinated transaction mode. The successful completion of a transaction is known as its commit. Unsuccessful completion is known as rollback. (See section XYZ for a long and complicated description of how to achieve it, be aware that it's not the default and that not all databases or queuing systems support it.)
The key feature of the coordinated transaction mode of operation is that either all the changes to queues and tables associated with one input message are made or none are made regardless of where or when failures occur and this is its key advantage. It does not suit all situations however. Two simple examples of such situations are:
MAIN -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1st AUX --------------x======x========x------ 3 6 7
The upper line represents the main transaction as before. Transaction is a rather abstract term but what it equates to in the real world is the extra data needed to restore the original state should the need arise. The lower line represents an auxiliary transaction. At time 3 an update to a table (or queue) is made. Another is made at time 6. At time 7 the flow decides that all the changes that need to be made under the auxiliary transaction are complete and commits the changes.
If the flow were to fail before time 7, the state of the system would be unchanged since both transactions would be rolled back. If failure occurs after time 7 but before time 9, the auxiliary transaction would be committed (it already has been) but the main one would be rolled back. If a failure hasn't occurred by time 9, there is no failure and both transactions are committed.
You are not restricted to a single auxiliary transaction and you are not restricted to only committing them. A number of updates can be made to database tables and these can be either committed or rolled back. You can then make some more changes to the same database tables, or to different tables, and then either commit or rollback these changes.
Each database that you use has its own auxiliary transaction and thus, if the flow updates tables belonging to different database instances (i.e. different data source names) there will be an auxiliary transaction per database. These may be (indeed must be) committed or rolled back individually. Any updates which have not been either committed or rolled back when the operation completes (time 9) will be automatically committed or rollback by the broker according to whether the processing succeeded or failed (i.e. whether an exception reaches the input node or not).
Note that some databases types, such as DB2 on AIX, do not allow both coordinated and uncoordinated transactions in the same database instance. In these cases, separate database instances must be created. You should configure one database instance for coordinated transactions and the other for uncoordinated transactions.
Auxiliary database transactions are committed or rolled back using the ESQL COMMIT and ROLLBACK statements. Operations outside the main transaction are obtained by specifying UNCOORDINATED on the individual database statements used, such as the INSERT and UPDATE statements.
Not all queuing systems have the capability of databases described above. In the case of MQ, each individual uncoordinated read or write to a queue has an implied commit. You cannot thus put two messages and then decide to commit them both or to roll them both back. This is a limitation of the underlying system which WebSphere Message Broker cannot hide. The COMMIT and ROLLBACK statements thus only operate on databases.
The above description talks only about flows and does not mention nodes. The way a flow is divided into nodes is, in principle, of no relevance to a discussion about transactions. Any number of nodes may make updates to the main and any number of auxiliary transactions in any way they see fit without restriction. What you do matters but how you do it does not. In practice however this is only true for operations on databases simply because other data sources (VSAM, Queues) have more limited capabilities.
A special case worth mentioning is when all database updates are done within auxiliary transactions. In this case, the "Coordinated Transaction" attribute of the message flow can be set to "no". This makes all table references outside the main transaction saving the trouble of having to specify it on each database operation. It may also make flows faster.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac07010_ |