Transactions are also supported by queues

docs/source/advancedDevelopment/integrationPatterns/transactions.rst

@@ -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.