You are here: Part 2: Core Concepts > Sending Data > DataWriter QosPolicies > OWNERSHIP QosPolicy


The OWNERSHIP QosPolicy specifies whether a DataReader receive 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 .



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 DDS, see Setting Topic QosPolicies.

How Connext DDS 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 OWNERSHIP_STRENGTH QosPolicy that is “alive” as defined by the LIVELINESS QosPolicy) and has not violated the DEADLINE QosPolicy of the DataReader. OWNERSHIP_STRENGTH is simply an integer set by the DataWriter.

If the Topic’s data type is keyed (see 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 DDS resolves the tie by choosing the DataWriter with the smallest GUID (Globally Unique Identifier, see 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:

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.


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


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.

Related QosPolicies

Applicable Entities

System Resource Considerations

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

© 2016 RTI