Locking and Concurrent Transaction Scheduling in GBase 8s (Part 2)

This article continues to explore the transaction processing capabilities of GBase 8s, revealing how it ensures ACID properties and effectively manages concurrent transactions.

Problems Caused by Locking

Locking techniques solve, to a certain extent, the data consistency problems caused by concurrent operations in database transaction processing, but they also introduce new issues such as livelock and deadlock.

The Livelock Problem

During concurrent transaction processing, if transaction T1 locks data object R, and transaction T2 also requests a lock on R, T2 must wait for T1 to release the lock. If transaction T3 then also requests a lock on R, and after T1 releases the lock the system first grants T3's request, T3 locks R while T2 still waits for T3 to release the lock. Then transaction T4 requests a lock on R, and after T3 releases its lock the system grants T4's request... T2 could wait forever without ever obtaining a lock on R. This is called livelock.

Livelock occurs because a transaction can never obtain the required lock. To avoid livelock, a first-come, first-served strategy can be adopted. When multiple transactions request a lock on the same data object, they are queued in the order of their lock requests. As soon as the lock on the data object is released, the first transaction in the queue is granted the lock.

The Deadlock Problem

If transaction T1 locks data object R1 and T2 locks data object R2, and then T1 requests a lock on R2, T1 must wait for T2 to release the lock on R2 because T2 has already locked it. Then T2 requests a lock on R1. Since T1 already holds the lock on R1, T2 must also wait for T1 to release the lock. Thus, T1 waits for T2 to release the lock on R2, while T2 waits for T1 to release the lock on R1. Both transactions are waiting for each other to release locks and can never proceed. This is a deadlock.

Deadlock: In a system, when two or more transactions are each waiting for another transaction to release a lock before they can proceed, none of them can continue. This situation is called a deadlock state in the database system.

A Simple Example to Reproduce a Deadlock

GBase mode (Session 1):

Then, two sessions, in the same database, both place shared (S) locks on tables a and b. When attempting to update, session 1 waits for session 2 to release the S lock on a, while session 2 waits for session 1 to release the S lock on b, leading to a deadlock.

In Oracle mode, however, this scenario does not produce a deadlock. This is because in GBase mode, after a transaction is started, it is possible to ensure that both sessions perform their updates before committing, enabling the two sessions to run concurrently.

In Oracle mode, only multi-statement mode is available. DML statements automatically start a transaction, which ends with COMMIT or ROLLBACK, and DDL statements implicitly commit the current transaction. As a result, the two sessions may not be able to run concurrently; parallelism becomes serialization, preventing a deadlock from occurring.

Conclusion

The transaction processing capabilities and concurrency control mechanisms of GBase 8s provide enterprises with a reliable, efficient, and secure data processing platform. Whether for financial transactions or online transaction processing, GBase 8s ensures data integrity and consistency, meeting the demanding requirements of enterprise database systems.