posted time Created time: 2017-02-09 Last updated time:

Implicit Row Lock and Parallel Transaction Commit

Distributed Relational Database Management Systems can commit transactions as parallel process. In order to implement that, implicit row lock is necessary.

Implicit Locks on Transaction Execution

When we start a transaction, and executing UPDATE, DELETE, and INSERT SQL Statements, they implicitly lock database objects.

UPDATE and DELETE SQL Statement

Implicit row lock is done on executing UPDATE, DELETE Statement, after started a transaction before end of it.

Both SQL Statements has WHERE clause in it. It requests scanning to storage engines. Then update lock is done for filtered rows.

After getting result from storage engines, the transaction engine filters the result, again. Then filtered row's lock is released.

The selected rows finally remain, and their locks are held while the transaction is active.

INSERT SQL Statement

When an INSERT Statement is executed amid a transaction, the lock is not done, immediately. But on executing COMMIT Statement, the transaction get INSERT Lock of the table.

The Insert Locks of the table common for all transactions. When the COMMIT Statement ends, the lock is released.

Alinous Elastic DB can configure scalability. Insert Lock is done by following distributed part.

Network Structure

Region Manager is  not Scalable

When the Region Master, which access the storages, is not scalable. The lock is done locally.

Region Manager is Scalable

When the Region Managers are scalable, they are not single points. Therefore the lock is done by Transaction Monitor.

Parallel Commit Execution

Transactions works independently, and they have possibility to execute COMMIT any time.

But database management system have to keep the consistency.

The storage engine of table is version control system, and it must not make branch of version.

By proper locking, it can do that by parallel execution.


Go to Top