You are here: Part 3: Advanced Concepts > Mechanisms for Achieving Information Durability and Persistence > Durable Writer History > How To Configure Durable Writer History

How To Configure Durable Writer History

Connext DDS allows a DataWriter’s history to be stored in a relational database that provides an ODBC driver.

For each DataWriter history that is configured to be durable, Connext DDS will create a maximum of two tables:

To configure durable writer history, use the PROPERTY QosPolicy (DDS Extension) associated with DataWriters and DomainParticipants.

A ‘durable writer history’ property defined in the DomainParticipant will be applicable to all the DataWriters belonging to the DomainParticipant unless it is overwritten by the DataWriter. lists the supported ‘durable writer history’ properties.

Durable Writer History Properties





Must be set to "dds.data_writer.history.odbc_plugin.builtin" to enable durable writer history in the DataWriter.



The ODBC DSN (Data Source Name) associated with the database where the writer history must be persisted.


Tells Connext DDS which ODBC driver to load. If the property is not specified, Connext DDS will try to use the standard ODBC driver manager library (UnixOdbc on UNIX/Linux systems, the Windows ODBC driver manager on Windows systems).


Configures the username/password used to connect to the database.

Default: No password or username



When set to 1, Connext DDS will create a single connection per DSN that will be shared across DataWriters within the same Publisher.

A DataWriter can be configured to create its own database connection by setting this property to 0 (the default).


These properties configure the resource limits associated with the ODBC writer history caches.

To minimize the number of accesses to the database, Connext DDS uses two caches, one for samples and one for instances. The initial size and the maximum size of these caches are configured using these properties.

The resource limits, initial_instances, max_instances, initial_samples, max_samples, and max_samples_per_instance defined in RESOURCE_LIMITS QosPolicy are used to configure the maximum number of samples and instances that can be stored in the relational database.


instance_cache_max_size: max_instances in RESOURCE_LIMITS QosPolicy

instance_cache_init_size: initial_instances in RESOURCE_LIMITS QosPolicy

sample_cache_max_size: 32

sample_cache_init_size: 32

If in_memory_state (see below in this table) is 1, instance_cache_max_size is always equal to max_instances in RESOURCE_LIMITS QosPolicy—it cannot be changed.





This property indicates whether or not the persisted writer history must be restored once the DataWriter is restarted.

If this property is 0, the content of the database associated with the DataWriter being restarted will be deleted.

If it is 1, the DataWriter will restore its previous state from the database content.

Default: 1


This property determines how much state will be kept in memory by the ODBC writer history in order to avoid accessing the database.

If this property is 1, then the property instance_cache_max_size (see above in this table) is always equal to max_instances in RESOURCE_LIMITS QosPolicy—it cannot be changed. In addition, the ODBC writer history will keep in memory a fixed state overhead of 24 bytes per sample. This mode provides the best ODBC writer history performance. However, the restore operation will be slower and the maximum number of samples that the writer history can manage is limited by the available physical memory.

If it is 0, all the state will be kept in the underlying database. In this mode, the maximum number of samples in the writer history is not limited by the physical memory available.

Default: 1

Durable Writer History is not supported for Multi-channel DataWriters (see Multi-channel DataWriters) or when Batching is enabled (see BATCH QosPolicy (DDS Extension)); an error is reported if this type of DataWriter tries to configure Durable Writer History.

See also: Durable Reader State.

© 2016 RTI