47.17 OWNERSHIP QosPolicy

The OWNERSHIP QosPolicy specifies whether a DataReader receives data for an instance of a Topic sent by multiple DataWriters.

For non-keyed Topics, there is only one instance of the Topic.

This policy includes the single member shown in Table 47.32 DDS_OwnershipQosPolicy.

Table 47.32 DDS_OwnershipQosPolicy


Field Name






The kind of OWNERSHIP can be set to one of two values:

This QosPolicy is often used to help users build systems that have redundant elements to safeguard against component or application failures. When systems have active and hot standby components, the Ownership QosPolicy can be used to ensure that data from standby applications are only delivered in the case of the failure of the primary.

The Ownership QosPolicy can also be used to create data channels or topics that are designed to be taken over by external applications for testing or maintenance purposes.

Although you can set the OWNERSHIP QosPolicy on Topics, its value can only be used to initialize the OWNERSHIP QosPolicies of either a DataWriter or DataReader. It does not directly affect the operation of Connext, see 18.1.3 Setting Topic QosPolicies.

47.17.1 How Connext Selects which DataWriter is the Exclusive Owner

When OWNERSHIP is EXCLUSIVE, the owner of an instance at any given time is the DataWriter with the highest 47.18 OWNERSHIP_STRENGTH QosPolicy that is “alive” as defined by the 47.15 LIVELINESS QosPolicy) and has not violated the 47.7 DEADLINE QosPolicy of the DataReader. OWNERSHIP_STRENGTH is simply an integer set by the DataWriter.

If the Topic’s data type is keyed (see Chapter 8 DDS Samples, Instances, and Keys), EXCLUSIVE ownership is determined on a per-instance basis. That is, the DataWriter owner of each instance is considered separately. A DataReader can receive values written by a lower strength DataWriter as long as those values are for instances that are not being written by a higher-strength DataWriter.

If there are multiple DataWriters with the same OWNERSHIP_STRENGTH writing to the same instance, Connext resolves the tie by choosing the DataWriter with the smallest GUID (Globally Unique Identifier, see 22.1 Simple Participant Discovery.). This means that different DataReaders (in different applications) of the same Topic will all choose the same DataWriter as the owner when there are multiple DataWriters with the same strength.

The owner of an instance can change when:

  • A DataWriter with a higher OWNERSHIP_STRENGTH publishes a value for the instance.
  • The OWNERSHIP_STRENGTH of the owning DataWriter is dynamically changed to be less than the strength of an existing DataWriter of the instance.
  • The owning DataWriter stops asserting its LIVELINESS (the DataWriter dies).
  • The owning DataWriter violates the DEADLINE QosPolicy by not updating the value of the instance within the period set by the DEADLINE.

Note however, the change of ownership is not synchronous across different DataReaders in different participants. That is, DataReaders in different applications may not determine that the ownership of an instance has changed at exactly the same time.

47.17.2 Example

OWNERSHIP is really a property that is shared between DataReaders and DataWriters of a Topic. However, in a system, some Topics will be exclusively owned and others will be shared. System requirements will determine which are which.

An example of a Topic that may be shared is one that is used by applications to publish alarm messages. If the application detects an anomalous condition, it will use a DataWriter to write a Topic “Alarm.” Another application that records alarms into a system log file will have a DataReader that subscribes to “Alarm.” In this example, any number of applications can publish the “Alarm” message. There is no concept that only one application at a time is allowed to publish the “Alarm” message, so in this case, the OWNERSHIP of the DataWriters and DataReaders should be set to SHARED.

In a different part of the system, EXCLUSIVE OWNERSHIP may be used to implement redundancy in support of fault tolerance. Say, the distributed system controls a traffic system. It monitors traffic and changes the information posted on signs, the operation of metering lights, and the timing of traffic lights. This system must be tolerant to failure of any part of the system including the application that actually issues commands to change the lights at a particular intersection.

One way to implement fault tolerance is to create the system redundantly both in hardware and software. So if a piece of the running system fails, a backup can take over. In systems where failover from the primary to backup system must be seamless and transparent, the actual mechanics of failover must be fast, and the redundant component must immediately pickup where the failed component left off. For the network connections of the component, Connext can provided redundant DataWriter and DataReaders.

In this case, you would not want the DataReaders to receive redundant messages from the redundant DataWriters. Instead you will want the DataReaders to only receive messages from the primary application and only from a backup application when a failure occurs. To continue our example, if we have redundant applications that all try to control the lights at an intersection, we would want the DataReaders on the light to receive messages only from the primary application. To do so, we should configure the DataWriters and DataReaders to have EXCLUSIVE OWNERSHIP and set the OWNERSHIP_STRENGTH differently on different redundant applications to distinguish between primary and backup systems.

47.17.3 Properties

This QosPolicy cannot be modified after the Entity is enabled.

It must be set to the same kind on both the publishing and subscribing sides. If a DataWriter and DataReader of the same topic are found to have different kinds set for the OWNERSHIP QoS, the ON_OFFERED_INCOMPATIBLE_QOS and ON_REQUESTED_INCOMPATIBLE_QOS statuses will be modified and the corresponding Listeners called for the DataWriter and DataReader respectively.

47.17.4 Related QosPolicies

47.17.5 Applicable Entities

47.17.6 System Resource Considerations

This QosPolicy does not significantly impact the use of system resources.