When you set the BLOCKING option to on, any transaction attempting to obtain a write lock that conflicts with an existing write lock held by another transaction waits until the conflicting lock is released, or until the BLOCKING_TIMEOUT threshold is reached. By default, BLOCKING is off.
Connection blocking puts the requesting transaction to sleep (blocking the table-level or row-level lock) until the connection holding the lock releases it (unblocking the table-level or row-level lock). You control the duration of the block by setting the BLOCKING_TIMEOUT value in milliseconds. When BLOCKING_TIMEOUT is 0 (the default), all blocked transactions in the connection wait indefinitely until the connection obtains the requested lock. When BLOCKING_TIMEOUT is set, and the lock is not released within the specified time, then the waiting transaction receives an error message.
Blocking takes advantage of delayed transaction versioning, where the transaction manager creates the transaction snapshot version after establishing a table-level or row-level lock.
With connection blocking disabled, User B's transaction is rolled back, and he or she receives an error indicating that another user has a lock on iq_table1.
With connection blocking enabled (and BLOCKING_TIMEOUT set to 0), User B's INSERT statement is put to sleep until User A's INSERT statement commits, releasing the table write lock.
With connection blocking enabled and BLOCKING_TIMEOUT set to 200 milliseconds, User B's transaction is rolled back and he or she receives an error indicating that another user has a lock on iq_table1, if User A's transaction does not commit within the 200 millisecond blocking timeout threshold.
For row-level lock examples, see Administration: In-Memory Row-Level Versioning > Manage Blocking in RLV Store.