Connection Blocking

Connection blocking blocks a statement until a server write-lock becomes available. The new connection blocking behavior enables competing write-transactions to establish their snapshot versions more efficiently and collaboratively, minimizing lock contention during table writes to the IQ main store and RLV store.

In earlier releases, when several clients attempted to perform write-operations against the same table, the server used a queuing mechanism to queue up waiting write requests while the table was locked by the write-transaction. Client applications used retry logic to send write-lock requests until the table was available for locking. However, the transaction snapshot version was created at transaction creation time, prior to obtaining the table write lock. It was possible, therefore, for a competing write-transaction to obtain the lock when the server put your transaction to sleep. In this scenario, when the server woke your transaction, the server noted that your version was older than the transaction committed by the other user, causing a future-version error and an inability to write.

Connection blocking is the mechanism where the server puts the connection to sleep and wakes it when the other connection releases the table write- lock. When you enable connection blocking, any transaction attempting to obtain a lock conflicting with an existing lock held by another transaction waits until either the conflicting lock is released, or until the blocking timeout value is reached. If the lock isn't released when the blocking timeout value is reached, then your waiting transaction receives an error.

When you disable connection blocking, your connection attempting to obtain the lock held by another connection receives an error immediately. The server rolls back the current operation.

Two database options support connection blocking:

In release 16.0, transaction snapshot versioning is delayed until your transaction obtains the table write-lock. This guarantees your transaction is blocked if another writer exists. Delayed transaction snapshot versioning is enabled by default, and requires no configuration.

See these topics in the SAP Sybase IQ 16.0 documentation:
Related concepts
Database Option Changes
RLV Data Store for Write-Optimized Storage