Symfony Lock

The Symfony Lock component creates and manages locks, a mechanism to guarantee exclusive access to a shared resource across processes, requests, or servers. It provides a single LockFactory/LockInterface API in front of a dozen interchangeable storage backends, so the same locking code can run against Redis, a relational database (via Doctrine DBAL or PDO), Memcached, MongoDB, ZooKeeper, a local flock, or a POSIX semaphore.

As one of Symfony’s decoupled components, it’s usable standalone in any PHP 8.4+ project (not just full Symfony applications) and is commonly reached for whenever multiple workers or requests must coordinate around a critical section — deduplicating cron jobs, serializing access to a resource, or implementing distributed rate limiting alongside symfony/rate-limiter.

What You Get

• A LockFactory that creates Lock objects from a Key, with acquire(), acquire(true) for blocking acquisition, refresh() to extend a TTL, and release().
• A dozen ready-made PersistingStoreInterface implementations: RedisStore, PdoStore, DoctrineDbalStore/DoctrineDbalPostgreSqlStore, MemcachedStore, MongoDbStore, ZookeeperStore, FlockStore, SemaphoreStore, InMemoryStore, and NullStore.
• A CombinedStore for quorum-based locking across multiple stores (the Redlock algorithm) so no single store is a single point of failure.
• Shared/read-write lock support via SharedLockInterface and BlockingSharedLockStoreInterface for stores that support it (e.g. RedisStore, SemaphoreStore).
• A Serializer layer for stores that need to persist lock metadata, plus a StoreFactory that builds the right store from a DSN string.

Common Use Cases

• Preventing a scheduled cron job or command from running twice concurrently across multiple servers.
• Serializing access to a shared resource (a file, an external API with rate limits, a database row) across concurrent web requests.
• Coordinating leader election or singleton-worker behavior in a horizontally scaled PHP application.
• Building distributed rate limiting or throttling logic on top of the lock primitive, often paired with symfony/rate-limiter.

Under The Hood

Architecture: A Lock (Lock.php) wraps a Key and delegates the actual acquire/refresh/release/exists calls to whichever PersistingStoreInterface it was constructed with, keeping the lock’s public API identical regardless of backend. Store/CombinedStore.php implements quorum-based (Redlock-style) locking by fanning the same operation out to multiple underlying stores and requiring a majority to succeed, which is how the component achieves resilience without a single-store bottleneck. LockFactory.php is the typical application-facing entry point, hiding store construction behind createLock($resource, $ttl, $autoRelease).

Tech Stack: PHP 8.4+, PSR-3 (psr/log) for optional logging, with dev-only dependencies on doctrine/dbal and predis/predis exercised only when those specific stores are used — the component has no hard runtime dependency on any particular storage driver, keeping the base install lightweight.

Code Quality: Tests/ mirrors the Store/, Serializer/, and Strategy/ directory structure with a dedicated PHPUnit test class per implementation (LockTest.php, LockFactoryTest.php, KeyTest.php, plus per-store tests), configured via phpunit.xml.dist. As part of the actively maintained symfony/symfony monorepo, it inherits Symfony’s shared CI, static analysis, and backward-compatibility policy across releases.

API Design: A single LockInterface and LockFactory cover acquire/refresh/release/shared-lock semantics uniformly across every backend, so switching from, say, a Redis store to a database store for local development is a one-line configuration change rather than a code change — the classic Symfony pattern of a stable interface over swappable adapters.