Lock-Free Reservations in Oracle 26ai: Comparing Traditional Locking and High-Concurrency Transactions

 

Introduction

Handling concurrent updates has always been a challenge in high-volume transactional systems. Consider a banking application where hundreds of transactions attempt to credit or debit the same account at the same time. With traditional row-level locking, once one session updates the account balance, other sessions must wait until the transaction commits or rolls back. As concurrency increases, this waiting can become a bottleneck, resulting in lock contention, increased response times, and events such as enq: TX - row lock contention.

One of the newer Oracle features designed to address this problem is Lock-Free Reservations. Instead of relying on immediate row locking for certain numeric updates, it allows concurrent transactions to reserve resources while preserving transactional consistency.

In this article, I will compare traditional row-level locking with Lock-Free Reservations using practical examples and see how each approach behaves under concurrent load.

This article is part of a small series on modern concurrency features in Oracle 26ai, including Lock-Free Reservations, transaction prioritization, and value-based concurrency control.

Real-World Oracle OCI PDB Refresh: Solving Clone Performance Bottlenecks Across Peered VCNs

 

Introduction

Recently, I had a task to refresh our UAT environment using a PDB from the production database hosted in Oracle Cloud Infrastructure (OCI).

At first, the activity looked straightforward. The plan was to perform a remote PDB clone from Production to UAT. However, there was one challenge from the beginning: the source and target databases were located in different OCI VCNs.

After establishing connectivity between the environments, I started the cloning process. The clone started successfully, but after approximately one hour, it appeared to stall, and no significant progress was observed.

After some investigation and testing, I identified two important factors that affected the cloning process:

• The target DBCS was running with only 1 OCPU.
• The production database had an hourly archive log backup and a delete job running through Commvault.

In this article, I will share the architecture, troubleshooting process, and lessons learned from this refresh activity.