Transactional Settings Concept Implementation in FESA3

XML Design

• marker for properties that are supposed to be transactional: attribute //equipment-model/interface/device-interface/setting/setting-property/set-action@transactional="true/false"
• missing: additional validation rules
• missing: possible extra fields to store error/status conditions (e.g. failed commit/rollback events)? Possibility to request status of transactions

FESA FWK

Status Quo

• fragments of implementation available (commit/rollback methods foreseen in ServerAction.h), no functionality yet
• missing: buffer handling of transactional setting parameters
• missing: multiplexing context requires field for transaction ID

Tasks

• Send TransactionID with set-action
• Set action writes to commit buffer, handling multiplexed fields and partial settings
• Handle commit/rollback events received from the WR timing network
• Commit event copies commit buffer to setting buffer immediately, no blocking on RT Actions. This possibly requires increasing the number of setting buffers.
• Notification mechanism for the success/failure of commit/rollback events
• Rollback discards current transaction.
• commit/rollback ID definitions should be institute-specific
• commit/rollback event trigger system to be institute-specific
• adaption of code generation for transactional properties
• user documentation of transactional design attribute //equipment-model/interface/device-interface/setting/setting-property/set-action@transactional="true/false" required (wiki, direct)
• !!!: shared memory (SAFTlib-related) might require rollback functionality for settings as well

Design Considerations

• TransactionID =0 to indicate non-transactional set to transactional property. Alternatives? TBD with responsibles
• transactional setting data arrives for property that is not transactional: an exception should be thrown TBD with responsibles
• If a transactionID is open, transactional setting data for another ID is discarded / an exception is thrown TBD with responsibles
• If a transactionID is open, is overwriting the transaction buffer with further transactional setting data for the same ID OK? TBD with responsibles
• If a transactionID is open, is a non-transactional set OK? TBD with responsibles

• commit: on commit the stored transactional settings will be sent to the device, the sender should be notified that the transactional setting occurred, how?
• commit: if no transactional settings are available on (unexpected) commit event arrival an exception should be thrown
• rollback: if transactional settings are taken back (rolled back) the transactional settings must be taken back from the device (which value will be used then? default value? alternative value sent by application?) and the transactional setting buffers must be emptied.
• It is assumed that transactional setting buffers are not persisted and do not need to survive a restart of the FESA equipment software.
• Recommendation: "intelligence" of transactional settings should be handled mainly by the transaction manager

• Possible impact of future FESA inheritance

CSCO / CCT / CSCOTG

• definition of commit- und rollback-Event ID
• confirm availability of a timing network connection for all devices with transactional settings TBD with responsibles