本文继续探讨南大通用GBase 8s数据库的事务处理特性，揭示其如何确保ACID特性，并有效管理并发事务。

封锁产生的问题

封锁技术在一定程度上解决了数据库的并发事务处理过程中，并发操作给数据库带来的数据一致性问题，但同时产生了新的问题如活锁和死锁。

活锁问题

在处理并发事务的过程中，如果事务T1在数据对象R上加锁，事务T2又请求为数据对象R加锁，则 T2 必须等待T1释放加在R上的锁。如果事务 T3 也请求为 R加锁，当T1释放了R上的锁之后系统首先响应T3的请求，则允许T3对R加锁，此时 T2 仍需等待T3 释放加在R上的锁。然后事务T4又请求封锁R，当T3释放了R上的封锁之后系统 又响应了T4的请求……T2有可能永远等待而无法为R加锁，这就是活锁（Live lock）。

活锁由于事务永远得不到封锁而导致。避免活锁可以采用先来先服务的策略。当多个事务请求封锁同一个数据对象时，可按照请求封锁的先后次序对事务排队，数据对象上的锁一旦释放就批准申请队列的第一个事务获得封锁。　

死锁问题

如果事务 T1 对数据对象 R1 进行封锁，T2 对数据对象 R2 进行封锁，然后 T1 又请求对 R2 进行封锁，由于 T2 已封锁了 R2，则 T1 必须等待 T2 释放 R2 上的锁。接着 T2 又申请对 R1 进行封锁，由于 T1 已封锁 R1，因此，T2 也只能等待 T1 释放 R1 上的锁。这样就出现了事务 T1 等待另一个事务 T2 释放相关数据对象上的锁，而 T2 又在等待 T1 释放相关对象上的锁，T1 和 T2 两个事务由于相互等待对方释放数据对象上的锁而永远不能继续执行，这样就出现了死锁。

死锁（Dead Lock）：系统中有两个或两个以上的事务都处于等待状态，并且每个事务都在等待其中另一个事务释放封锁，这样才能继续执行下去，结果造成任何一个事务都无法继续执行，这种现象称数据库系统进入了“死锁”（Dead Lock）状态。

用例简单复现死锁产生

GBase模式下（会话1）：

那么两个会话分别在同一个库中，对a表和b表加上共享锁S，当想进行更新时，会话1在等待会话2释放a的S锁，而会话2在等待会话1释放b的S锁，从而导致死锁产生。

那么在oracle模式下，该用例却不能产生死锁。因为在GBase模式下，开启事务后，可以保证两个会话在执行更新后才提交保证两个会话同时进行。

而在oracle模式下，只能开启多语句模式，DML语句会自动开启事务，通过commit/rollback结束事务，DDL会提交事务。从而导致两个会话可能无法同时进行，因此并行变成串行，导致死锁无法产生。

写在最后

南大通用GBase 8s数据库的事务处理能力和并发控制机制，为企业提供了一个可靠、高效和安全的数据处理平台。无论是金融交易还是在线事务处理，GBase 8s都能确保数据的完整性和一致性，满足企业对数据库系统的要求。