A message flow can consist of the following constituent parts:
A typical sequence of events when a message flow processes a message is described below:
Note that this sequence of events makes no distinction between accessing tables and writing output messages. Although a flow often produces some sort of output message, there is no real distinction between producing an output message and updating a database table; in both cases, the state of the data in the system changes.
=====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, data is used to update database tables or it is written to queues. Changes in the state of the data are indicated in the diagram by the x symbol. At time 6, the output messages are sent and the system is inactive. Between these events, there is no change to the state of the data; this is indicated in the diagram by the = symbol.
If a failure occurs on the system (for example, a loss of power to the computer on which the broker is running), the changes to the state of tables and queues that were made before the failure have taken place, but no more changes will take place after the failure. This situation is unacceptable in certain circumstances; for example, if a system failure occurs when making a payment from a current account to a mortgage account, the payment might be taken from the current account, but it is not added to the mortgage account.
-----x=========x===x=======x=============x====x----- 1 2 3 4 5 6
The line in the diagram represents the extra data in the system as time passes. At time 1, a message arrives and is taken from the input queue. Before time 1, there is no extra data in the system; this is indicated in the diagram by the - symbol. After time 1, the state represents the fact that a message has been taken from the queue so that it can be put back on the queue if necessary. At times 2, 3, 4, and 5, data is used to update database tables or it is written to queues. Again, the state of the extra data changes so that the changes to tables and queues can be undone if necessary. At time 6, the output messages are sent, the system is inactive, 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 time 1 and time 6, the extra data is used to restore the original state of the system's data, so effectively, no data has been written to the output queues, none of the tables have been updated, and the input message has not been taken from the input queue. If no failure occurs, the changes become permanent at time 6 (an undo operation following a subsequent failure will not undo the changes).
The mode of operation that is described above is known as coordinated transaction mode. The successful completion of a transaction is known as its commit. Unsuccessful completion is known as rollback.
The key feature of the coordinated transaction mode of operation is that, regardless of where or when the failure appears, either all of the changes to queues and tables that are associated with one input message are made, or none of the changes are made. However, this behavior is not always suitable, as the following examples illustrate:
MAIN -----x=========x===x=======x=============x====x----- 1 2 4 5 8 9 1st AUX --------------x======x========x------ 3 6 7
The MAIN line represents the main transaction, which includes the extra data that is needed to restore the original state should the need arise. The 1st AUX line represents an auxiliary transaction. At time 3, an update to a table or queue is made and another update is made at time 6. At time 7, the message flow determines that all the changes that need to be made under the auxiliary transaction are complete and it commits the changes.
If the message flow were to fail before time 7, the state of the system would be unchanged because both transactions would be rolled back. If failure occurs after time 7 but before time 9, the auxiliary transaction would already have been committed but the main transaction would be rolled back. If a failure has not occurred by time 9, both transactions are committed.
You can use more than one auxiliary transaction and make a number of updates to database tables that can be committed or rolled back. You can then make additional changes to the same database tables, or to different tables, and then commit or rollback these changes.
Each database that you use has its own auxiliary transaction so, if the message flow updates tables that belong to different database instances (different data source names), there is an auxiliary transaction for each database. You must commit or roll back these transactions individually. Any updates that have not been committed or rolled back when the operation completes (at time 9 in the example above) are committed or rolled back automatically by the broker, according to whether the processing succeeded or failed.
Some databases types, such as DB2 on AIX, do not allow both coordinated and uncoordinated transactions in the same database instance. In these cases, you must create separate database instances. Configure one database instance for coordinated transactions and configure the other instance for uncoordinated transactions.
Use the ESQL COMMIT and ROLLBACK statements to commit and roll back auxiliary database transactions. Obtain operations outside the main transaction by specifying the UNCOORDINATED keyword on the individual database statements (for example, the INSERT and UPDATE statements).
Not all queuing systems have the database capability that is described above. In the case of WebSphere MQ, each individual uncoordinated read or write operation to a queue has an implied commit action so you cannot put two messages and then decide to commit both or roll back both. The COMMIT and ROLLBACK statements therefore operate only on databases.
The above description mentions message flows but does not mention nodes. The way that a message flow is divided into nodes has no effect on transactions. For operations on databases, any number of nodes can make updates to the main transaction and to any number of auxiliary transactions without restriction.
When all database updates are done within auxiliary transactions, set the Coordinated Transaction attribute of the message flow to no to affect all table references outside the main transaction. This means that you do not have to specify the attribute on each database operation.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac07010_ |