Data consistency and concurrency

Data consistency involves readers that want to access data currently modified by writers, and concurrency data access involves several writers accessing the same data for modification. Locking granularity defines the amount of data concerned when a lock is set (row, page, table, ...).

Informix®

Informix uses a locking mechanism to handle data consistency and concurrency. When a process changes database information with UPDATE, INSERT or DELETE, an exclusive lock is set on the touched rows. The lock remains active until the end of the transaction. Statements performed outside a transaction are treated as a transaction containing a single operation and therefore release the locks immediately after execution. SELECT statements can set shared locks according to the isolation level. In case of locking conflicts (for example, when two processes want to acquire an exclusive lock on the same row for modification or when a writer is trying to modify data protected by a shared lock), the behavior of a process can be changed by setting the lock wait mode.

Control:

Defaults:

PostgreSQL

When data is modified, exclusive locks are set and held until the end of the transaction. For data consistency, PostgreSQL uses a multi-version consistency model: A copy of the original row is kept for readers before performing writer modifications. Readers do not have to wait for writers as in Informix. The simplest way to think of the PostgreSQL implementation of read consistency is to imagine each user operating a private copy of the database, hence the multi-version consistency model. The lock wait mode cannot be changed as in Informix. Locks are set at the row level in PostgreSQL and this cannot be changed.

Control:

Defaults:

The main difference between Informix and PostgreSQL is that readers do not have to wait for writers in PostgreSQL.

Solution

The SET ISOLATION TO ... Informix syntax is replaced by SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ... in PostgreSQL. The next table shows the isolation level mappings done by the PostgreSQL database driver:

Table 1. Isolation level mappings done by the PostgreSQL database driver
SET ISOLATION instruction in program Native SQL command
SET ISOLATION TO DIRTY READ

SET SESSION CHARACTERISTICS AS

TRANSACTION ISOLATION LEVEL READ COMMITTED

SET ISOLATION TO COMMITTED READ

[READ COMMITTED] [RETAIN UPDATE LOCKS]

SET SESSION CHARACTERISTICS AS

TRANSACTION ISOLATION LEVEL READ COMMITTED

SET ISOLATION TO CURSOR STABILITY

SET SESSION CHARACTERISTICS AS

TRANSACTION ISOLATION LEVEL READ COMMITTED

SET ISOLATION TO REPEATABLE READ

SET SESSION CHARACTERISTICS AS

TRANSACTION ISOLATION LEVEL SERIALIZABLE

For portability, it is recommended that you work with Informix in the read committed isolation level, make processes wait for each other (lock mode wait), and create tables with the "lock mode row" option.

See the Informix and PostgreSQL documentation for more details about data consistency, concurrency and locking mechanisms.