The transactional model

To avoid the problem that is described previously, the broker and the external resource managers with which it works, have a transactional model. The broker starts a transaction when data is received by an input node in the message flow, and completes when the processing on that data is finished. For more details about message flow transactions, see Message flow transactions.

	-----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, input data arrives from the input source; for example, a queue. Before time 1, no extra data exists in the system; this state is indicated in the diagram by the - symbol. After time 1, the state represents the fact that data has been received from the input source, so that it can be restored, if necessary. At times 2, 3, 4, and 5, data is used to update external resources such as databases or files. Again, the state of the extra data changes so that the changes to those external resources can be undone, if necessary. At time 6, the output messages are sent, the system is inactive, and extra data in the system no longer exists.

Between these events, the state of the extra data does not change; this state is indicated by the = symbol. If a failure occurs between time 1 and time 6, the extra data is used to restore the original state of the data held by the external resources. Therefore, effectively, no output data has been written to the output target, none of the external resources have been updated, and the input data has not been received from the input source. If no failure occurs, the changes become permanent at time 6 (an undo operation that follows a subsequent failure will not undo the changes).

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.

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 external resources 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:

• You want to create an audit log of all attempts at processing. The log entries must be committed, even when updates to other resources are rolled back.
• You want to send an acknowledgment or non-acknowledgment message back to the originator of the messages that you are processing, according to whether the message processing succeeds or fails. These messages must be sent even when the updates to other resources are rolled back.

If your message flows have requirements like these, you can configure message flows to change one or more resources in a separate, or auxiliary, transaction. Not all resource managers support this type of transaction.

For some resources, an auxiliary transaction is automatically started; for example, each database connection starts a transaction that is specific to that database, and all updates made in that transaction can be committed or rolled back.

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 recorded to restore the original state if necessary. The 1st AUX line represents an auxiliary transaction. At time 3, an external resource is updated, and another update is made at time 6. At time 7, the message flow determines that all the changes that must be made under the auxiliary transaction are complete, and it commits the changes.

If the message flow fails 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. However, 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, then commit or rollback these changes.

Each database that you use has its own auxiliary transaction; therefore, if the message flow updates tables that belong to different database instances (different data source names), an auxiliary transaction exists for each database. You can optionally commit or roll back these auxiliary transactions individually. Updates that have not been committed or rolled back when the message flow completes (at time 9 in the example shown previously) are committed or rolled back automatically by the broker, according to whether the processing succeeded or failed.

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 in the previous section. With WebSphere® MQ, each individual uncoordinated read or write operation to a queue has an implied commit action. Therefore, you cannot put two messages, then decide to commit both or roll back both. The COMMIT and ROLLBACK statements therefore operate only on databases.

The previous sections refer to message flows, but not to nodes. The way in which a message flow is divided into nodes has no effect on transactions. For operations on databases, an unlimited number of nodes can make updates to the main transaction, and to an unlimited number of auxiliary transactions, without restriction.