An ACX request can explicitly specify transaction tokens (transactionStart, transactionCommit, transactionRollback) that cause a TMF Transaction to be started, committed or aborted. All Pathway servers activated after a transaction is started run under that TMF transaction. This enables full control over the transaction boundary. By using persistent connections you can also have the TMF transaction span more than one ACX request.

If no transaction tokens are provided in the ACX request, the ACX dispatcher assumes you are working in autocommit mode. In this case, the dispatcher calls the adapter to start a transaction before the first interaction is run and commits the transaction after the last interaction is run. Thus, each ACX request is a single TMF transaction; whether it is a single interaction request or a batch request with several interactions in it.

If you do not want a TMF transaction to be started by AIS (for example, with Pathway servers that control the transactions themselves (start and commit a transaction), then transaction support should be disabled in the adapter configuration.

TMF transactions are coordinated across the server so that you can use the same server to run a Pathway server as well as access SQL/MP and Enscribe audited files directly from Attunity Connect, all within the same TMF transaction.

The dispatcher will rollback a TMF transaction if the Pathway server returns SERVERCLASS_SEND with a non-zero status.

An error condition that should cause a rollback of the TMF transaction should be handled by the Pathway server returning the actual error.