Lock Management

Row locks, and their prerequisite write-intent locks, ensure consistency between concurrent transactions at a row level. For example, a transaction can lock a particular row to prevent another transaction from changing it. Transactions place write-intent locks on the table itself, and on the table rows they intend to modify, to prevent conflicts from both competing row-level and table-level snapshot-versioned transactions.

An RLV-enabled table uses row locks for updated and deleted rows; and write-intent locks when accessed by read-write transactions with row-level snapshot versioning. The IQ write table lock is used when accessed by read-write transactions with table-level snapshot versioning.

DDL changes to an RLV-enabled table require an exclusive table-level lock; the writing connection has an exclusive lock on the table. DML changes to an RLV-enabled table first take out a write-intent lock to block table-level versioned transactions from locking the table, and then take out a row-level lock to prevent other row-level versioned transactions from writing to those rows.

• Schema Locks
  Whereas a table-lock in the IQ main store places a lock on all the rows in the table, a schema lock places a lock on the table's schema.
• Row Locks
  A row lock is a table-row write lock that allows the holding transaction to write to any column of a locked row. Only one holder of this lock can exist at a time. A write-intent lock is a prerequisite; the transaction must hold a write-intent lock before the lock manager grants it a row lock.
• Write-Intent Locks
  A write-intent lock is a table write lock that grants the transaction permission to write to a table row in the future. A write-intent lock can be held by multiple requesting connections.
• Table-Level DML Locking Considerations
  If a table is enabled for RLV storage, you can still issue table-level snapshot versioning DML statements against it. The DML engine recognizes table-level and row-level versioned transactions, and manages the locks accordingly.
• Row-Level DDL Locking Considerations
  Data Definition Language (DDL) changes (for example, CREATE INDEX, DROP INDEX, and ALTER TABLE ADD, ALTER, or DROP) to an RLV-enabled table require an exclusive table-level lock. For DDL events, the locking behavior for an RLV-enabled table is the same as for an IQ main store table: the writing connection has an exclusive lock on the table. When BLOCKING is set to ON, all competing DML and DDL transactions against the table are blocked until the DDL changes are committed. When BLOCKING is set to OFF, the competing transaction will immediately fail the lock request.