Skip to content

Commit

Permalink
Transactions are also supported by queues
Browse files Browse the repository at this point in the history
  • Loading branch information
Martijn Dirkse committed Sep 16, 2024
1 parent a6efc15 commit 11fc96d
Showing 1 changed file with 1 addition and 1 deletion.
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ Transactions

Transactions ensure that manipulations of data are either done correctly or not at all. The typical example is money transfer. When some person A pays person B, then A's balance has to be reduced and B's balance has to be increased. Without transactions, it would be possible that A's balance were reduced while an error occurred increasing B's balance, causing a loss of money. With transactions in place, the transaction becomes atomic. Either A's balance is reduced *and* B's balance is increased, or both A's balance and B's balance are unmodified in case of an error.

Transactions are supported by databases. In Frank configurations, it is possible to manipulate the transactions applied by the underlying database. In addition, it is possible to work with XA transactions, transactions that run over multiple databases. That will be covered later. This section focuses on transactions that apply to a single database.
Transactions are supported by databases and by queues. In Frank configurations, it is possible to manipulate the transactions applied by an underlying database. In addition, it is possible to work with XA transactions, transactions that run over multiple databases and queues. That will be covered later. This section focuses on transactions that apply to a single database.

Transactions are configured in a ``<Receiver>`` or in a ``<Pipeline>``, in both of them using attribute ``transactionAttribute``. Possible values of this attribute are ``Required``, ``RequiresNew``, ``Mandatory``, ``NotSupported``, ``Supports`` and ``Never``. The exact meaning of these values can be found in the Frank!Doc. When the receiver of an ``<Adapter>`` has ``transactionAttribute="Required"``, then all data manipulations done by the receiver itself and by the pipeline are meant to happen in the same (database) transaction. When another adapter is called, the logic in that sub-adapter can happen in the same transaction depending on the ``transactionAttribute`` configured in the sub-adapter's ``<Receiver>`` or ``<Pipeline>``. When the ``transactionAttribute`` is set on the ``<Pipeline>``, the data manipulations done by the receiver are excluded from the transaction.

Expand Down

0 comments on commit 11fc96d

Please sign in to comment.