Transactions in FESA

Overview

Transactions in FESA allow setting values to be written into a transaction buffer ahead of time and committed (or rolled back) with a timing event, enabling synchronzied activation of new setting values across many devices. For testing purposes, transactions can also be committed via RDA calls..

The initial FESA release with transaction support is 8.1.0

FESA Design

A FESA Setting Property can be marked as "Transactional" in the design. Non-transactional properties behave as normal with setting properties immediately available to Realtime Actions.

FESA User Code

When using a Default Action, nothing needs to be done. A Custom Set Action must write only to FESA-managed setting data items.

Transaction Bounds

Each setting data-item slot has a single transaction buffer. This results in the following limits:

A single transaction may be open for each (Device, Context) pair. (e.g. Device1/BeamProcess1, Device2/BeamProcess2, Device1/BeamProcess1 may all have different transactions open)

A new transaction cannot be opened before the previous transaction is retired (commit/rollback/otherwise discarded).

All transactional properties for a (Device, Context) commit / rollback together.

Behaviour

If no transaction is open, sets to a transactional property are executed directly.

Once a transaction is open, writes to a non-transactional property are still executed directly.

Once a transaction is open, all writes are redirected to the transaction buffer. Multiple writes are allowed.

On a commit, the transaction buffer is copied to the setting buffer and will be used for the next realtime event. On a rollback the transaction buffer is discarded. Commit/Rollback close the transaction.

On a test, the FESA software can check that the transaction buffer could be successfully committed, and the transaction remains open.

Transaction IDs

The TransactionID is 16 bits and should be unique. A global source of TransactionIDs is required

Details

A transaction is opened by sending an RDA data packet containing the transactionID to the property named "TRANSACTION.ID" of the Device/MultiplexingContext being used.
If there are no transactional properties or a transaction is already open, this will fail.
Once the transaction is open, all sets are redirected to the transaction buffer. Multiple sets may be carried out.

When a transaction is committed, the transaction setting buffer is copied to the setting buffer that is visible to the Realtime Actions. This uses the same buffer synchronization mechanism as a conventional set: there are two setting buffers that may be locked for reading by realtime actions; when one is free the transaction buffer is copied and is used by the next Realtime Action.

A transaction is committed by either:
A timing event
An RDA data packet containing the transactionID to the property named "TRANSACTION.COMMIT" of the Device/MultiplexingContext being used.
A transaction is rolled back by either:
A timing event
An RDA data packet containing the transactionID to the property named "TRANSACTION.ROLLBACK" of the Device/MultiplexingContext being used.

In Progress

Test events

A "Test" asks the FESA software to confirm that a commit would work given the current state of the transaction

FESA User code

New virtual functions in the Set Action for commit, pre-commit, test, rollback

Timing interface

The FESA software requires Timing events that trigger commit/rollback/test.
Devices in different timing groups may commit separately.

References

https://wikis.cern.ch/display/FESA3/Transactions+in+FESA

https://wikis.cern.ch/display/COTEC/Transactions+support+in+the+Control+System

-- DominicDay - 13 Apr 2022