Concurrently running transactions in an application results in hard-to-debug data consistency and deadlock issues. A mechanism is needed to avoid these race conditions and deadlocks. First, the transaction must acquire locks to achieve isolation, and then, to prevent deadlocks, one needs to ensure objects are locked in a pre-defined priority order, as there is no static way of reporting locking-order violations.

We’ve built a system in one of our core analytical engines to ensure that transactions follow locking order during runtime. When following the locking order is not feasible, it identifies the transaction resulting in a deadlock and victimizes that transaction.

Session Objective:

In a running application, the landscape of locks held by transactions and the locks it is waiting to acquire are ever-changing. Through this demonstration, we plan to showcase the design and approach of a lock management system, which can be helpful for developers working on multi-threaded applications.