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.
The write-intent lock conflicts with table write locks and table exclusive locks. This conflict prevents a table-level snapshot-versioned transaction from writing to the table or performing a DDL operation until the lock manager releases all write-intent locks on the table.