Principle:Apache Shardingsphere Exclusive Operation Management

Knowledge Sources	Apache_Shardingsphere ShardingSphere Mode
Domains	Distributed_Systems, Concurrency
Last Updated	2026-02-10 00:00 GMT

Overview

Mechanism for ensuring mutually exclusive execution of critical operations across distributed ShardingSphere nodes using pluggable distributed locking.

Description

Exclusive Operation Management ensures that certain metadata-mutating operations (such as statistics refresh, schema changes, and storage unit modifications) execute on only one node at a time in a clustered ShardingSphere deployment. The system uses a pluggable distributed lock abstraction (DistributedLock) that can be backed by ZooKeeper, etcd, or a default repository-based implementation. An ExclusiveOperatorEngine wraps the lock acquisition/release lifecycle around operation callbacks with configurable timeouts.

Usage

Apply this principle when designing operations that must be serialized across cluster nodes to prevent concurrent modifications to shared metadata state. In standalone mode, a local ReentrantLock provides the same semantics without network coordination.

Theoretical Basis

The core mechanism follows the distributed mutual exclusion pattern:

Pseudo-code Logic:

// Abstract algorithm (NOT real implementation)
lock = distributedLockProvider.getLock(operationPath)
if lock.tryLock(timeoutMillis):
    try:
        result = callback.execute()
    finally:
        lock.unlock()
else:
    throw TimeoutException("Could not acquire exclusive lock")

The lock implementations vary by backend:

ZooKeeper: Uses Curator's InterProcessMutex (recipe-based ephemeral sequential nodes)
etcd: Uses etcd's native Lock and Lease APIs with TTL-based expiration
Default: Uses repository persist/delete with thread-local reentrant tracking

Related Pages

Page Connections

Double-click a node to navigate. Hold to expand connections.

Principle

Implementation

Heuristic

Environment