Isolation Levels

AttentionThis page documents an earlier version. Go to the latest (v2.1)version.

YugabyteDB currently implements SnapshotIsolation, also known as SI, which is antransaction isolation level that guarantees that all reads made in a transaction will see aconsistent snapshot of the database, and the transaction itself will successfully commit only if noupdates it has made conflict with any concurrent updates made by transactions that committed sincethat snapshot. We are also working on supporting theSerializable#Serializable) isolationlevel, which would by definition guarantee that transactions run in a way equivalent to a serial(sequential) schedule.

Locks for isolation levels

In order to support these two isolation levels, the lock manager internally supports three typesof locks:

• Snapshot Isolation Write Lock. This type of a lock is taken by a snapshot isolationtransaction on values that it modifies.
• Serializable Read Lock. This type of a lock is taken by serializable read-modify-writetransactions on values that they read in order to guarantee they are not modified until thetransaciton commits.
• Serializable Write Lock. This type of a lock is taken by serializable transactions on valuesthey write, as well as by pure-write snapshot isolation transactions. Multiple snapshot-isolationtransactions writing the same item can thus proceed in parallel.

The following matrix shows conflicts between locks of different types at a high level.

Fine grained locking

We make further distinction between locks acquired on a DocDB node that is being written to by anytransaction or read by a read-modify-write serializable transaction, and locks acquired on itsparent nodes. We call the former types of locks “strong locks” and the latter “weak locks”. Forexample, if an SI transaction is setting column col1 to a new value in row row1, it willacquiire a weak SI write lock on row1 but a strong SI write lock on row1.col1. Because of thisdistinction, the full conflict matrix actually looks a bit more complex:

Here are a couple of examples explaining possible concurrency scenarious from the above matrix:

• Multiple SI transactions could be modifying different columns in the same row concurrently. Theyacquire weak SI locks on the row key, and strong SI locks on the individual columns they arewriting to. The weak SI locks on the row do not conflict with each other.
• Multiple write-only transactions can write to the same column, and the strong serializable writelocks that they acquire on this column do not conflict. The final value is determined using thehybrid timestamp (the latest hybrid timestamp wins). Note that pure-write SI and serializablewrite operations use the same lock type, because they share the same pattern of conflicts withother lock types.