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.
When we start a transaction, and executing UPDATE, DELETE, and INSERT SQL Statements, they implicitly lock database objects.
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.
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.
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.
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.