Shared Database Concurrency
summary
A payment system built in C++ with an Oracle database and Tuxedo application server handles customers with 31 million cards and >1 billion yearly transactions, peaks ~250 tps online and thousands tps in batch. A custom low‑level C++ library and rowid lookups reduce DB work, and defaulting to implicit locking plus relative updates avoids retry storms; targeted pessimistic locks cover rare hot rows. Reordering statements yields up to 50% faster; removing distributed transactions gives ~20% gain; commit‑on‑DML ~10%.
AI-written summary · about
chapters (8)
- 0:00Start
- 4:52Shared memory concurrency
- 5:52Shared database concurrency
- 12:46Pessimistic vs. Optimistic
- 14:06"Implicit" vs. Optimistic
- 16:54How to choose locking
- 22:12Increase performance
- 26:00Reduce lock granularity
related talks
16mScaleDB: A Scalable, Asynchronous In-Memory Database
11mChallenges Deploying Modern Real-Time Payment Systems on Traditional RDBMS
18mTowards a Lightning Fast System: Migrating a Real-Time Payment Service to
23mScalable Architecture for Processing UPI Real-Time Transactions Using Distributed SQL
49m10ms Response with Transactions, Big Data, Flexible Logic and OpenSource
42mA Race To The Bottom: Database Transactions Undermining Your AppSec
54mDistributed Caching in Real-Time Payment Systems
34mCrafting the Core - Why and How We Built the Core Banking System