The term durability is used to mean that once a transaction is committed, it remains committed regardless of subsequent failures. A highly durable system is one where loss of a committed transaction is extermely unlikely, whereas with a less durable system loss of a transaction is likely in a greater number of scenarios. Typically, the more highly durable a system the slower and more costly it will be.
Qpid exposes the all the durability controls offered by by BDB JE JA and a Qpid specific optimisation called coalescing-sync which defaults to enabled.
BDB expresses durability as a triplet with the following form:
<master sync policy>,<replica sync policy>,<replica acknowledgement policy>
The sync polices controls whether the thread performing the committing thread awaits the successful completion of the write, or the write and sync before continuing. The master sync policy and replica sync policy need not be the same.
Note: the combination of a master sync policy of SYNC and coalescing-sync true would result in poor performance with no corresponding increase in durability guarantee. It cannot not be used.
The acknowledgement policy defines whether when a master commits a transaction, it also awaits for the replica(s) to commit the same transaction before continuing. For the two-node case, ALL and SIMPLE_MAJORITY are equal.
If enabled (the default) Qpid works to reduce the number of separate file-system sync operations performed by the master on the underlying storage device thus improving performance. It does this coalescing separate sync operations arising from the different client commits operations occuring at approximately the same time. It does this in such a manner not to reduce the ACID guarantees of the system.
Coalescing-sync has no effect on the behaviour of the replicas.
The default durability guarantee is
NO_SYNC, NO_SYNC, SIMPLE_MAJORITY with coalescing-sync enabled. The effect
of this combination is described in the table below. It offers a good compromise between durability guarantee and performance
with writes being guaranteed on the master and the additional guarantee that a majority of replicas have received the
Here are some examples illustrating the effects of the durability and coalescing-sync settings.
Table 12.1. Effect of different durability guarantees
|1||NO_SYNC, NO_SYNC, SIMPLE_MAJORITY||true||Before the commit returns to the client, the transaction will be written/sync'd to the Master's disk (effect of coalescing-sync) and a majority of the replica(s) will have acknowledged the receipt of the transaction. The replicas will write and sync the transaction to their disk at a point in the future governed by ReplicationMutableConfig#LOG_FLUSH_INTERVAL.|
|2||NO_SYNC, WRITE_NO_SYNC, SIMPLE_MAJORITY||true||Before the commit returns to the client, the transaction will be written/sync'd to the Master's disk (effect of coalescing-sync and a majority of the replica(s) will have acknowledged the write of the transaction to their disk. The replicas will sync the transaction to disk at a point in the future with an upper bound governed by ReplicationMutableConfig#LOG_FLUSH_INTERVAL.|
|3||NO_SYNC, NO_SYNC, NONE||false||After the commit returns to the client, the transaction is neither guaranteed to be written to the disk of the master nor received by any of the replicas. The master and replicas will write and sync the transaction to their disk at a point in the future with an upper bound governed by ReplicationMutableConfig#LOG_FLUSH_INTERVAL. This offers the weakest durability guarantee.|