DDS — Transactional_reliability Issue

Issue# 2060 Transactional_reliability Issue [Boeing SOSCOE] ? For the case of Point2Point and Group communications there is a need to have “application-level” reliability where the sender can find out if a message was (1) delivered to the receiving application(s) and (2) whether it was successfully processed by the receiving application(s). ? SOSCOE uses the name “TRANSACTIONAL” to refer to this kind of application-level message-processed confirmation. ? This would only make sense for HISTORY QoS KEEP_ALL. TRANSACTIONAL and KEEP_LAST would be considered inconsistent QoS settings. Proposal [Boeing SOSCOE] ? Add the kind TRANSACTIONAL to Reliability QoS policy ? Add DataReader::set_transaction_status (or some operation to allow receiving application to accept or reject a transactional message) ? Add listener operations to the DataWriter to get notified of the transactional status. Potentially add also a method to the DataWriter to query the transactional status. ? Add a DataWriter::rewrite(WriteMessageID). This only applies to EndpointConnectors or GroupConnectors that have transactional QoS set. This handles the case where the message was transmitted to the receiving end and put on the reader queue successfully but the reading application does not set the transactional status indicating that the message was processed. The rewrite() is a convenience so that the writing application does not have to re-create the message but is being treated by the infrastructure as a message that needs to be sent again because the reader has presumably erased it from its queues.

duplicate, close issue