Replicated transactions and concurrency

Replicated transactions on a primary NPS node can execute with any mix of serializable isolation and snapshot isolation (relaxed serializability).

A DBMS provides serializable isolation if it enforces serializable execution of transactions (for those transactions that choose or default to serializable isolation). An implementation of serializable isolation generally offers less concurrency and lower throughput than that of a weaker isolation level.

Netezza by default supports only serializable transaction isolation. Only replication transactions support the snapshot isolation. For more information about Transaction Isolation in Netezza, see Transaction concurrency and isolation.

Under snapshot isolation, each transaction sees a consistent “snapshot” of the database that reflects just those transactions that were committed when the particular transaction started. Also, updates and deletes of the same row by concurrent transactions are disallowed. (Some DBMSs enforce the latter property at transaction commit time; NPS enforces it when the concurrent update or delete statement is executed.) Netezza® supports snapshot isolation for applications that require greater concurrency than serializable isolation allows and can trade off enforcement of inter-row consistency constraints. Snapshot isolation is supported for replicated transactions with IBM® Netezza Replication Services 2.0 and later.

The commit order of replicated transactions on the primary defines the order in which the transactions are applied on a replica NPS node. Each replicated transaction is assigned an increasing commit sequence number (CSN) at commit time, which is used to track the transaction and appears in various replication views and logs. A commit sequence identifier (CSI) is a <source-id>, <CSN> pair, where <source-id> identifies the primary node at the time that the active transaction was committed.