Product Decisions This Supports

Enables reliable scaling of RoadRunner-based applications by providing a standardized solution for distributed locking, eliminating the need for custom race-condition mitigation code.
Reinforces the strategic bet on RoadRunner as a high-performance PHP server: with 1.2.0, the package tracks RoadRunner v3, so our locking layer stays aligned with the current server generation rather than pinning us to a legacy runtime.
Justifies "buy" over "build" for lock management due to minimal maintenance overhead, RoadRunner-specific optimization, and adherence to PHP's execution model—reducing technical debt in concurrency-heavy features.
The package rename to roadrunner/lock (from the previous vendor namespace) is a roadmap and dependency-hygiene decision: it signals the locking integration is now a first-party RoadRunner component, which improves long-term support expectations and simplifies our dependency review process.
Use cases include shared resource access (e.g., database updates, cache invalidation) and multi-step transactions where data consistency is non-negotiable.

When to Consider This Package

When your application uses RoadRunner and requires lightweight, low-latency distributed locking for long-running workers.
When you are on, or planning to move to, RoadRunner v3—1.2.0 is the release that adds v3 support, so it becomes the minimum viable version for any v3 roadmap work.
When you need a zero-external-dependency solution that integrates natively with RoadRunner's architecture (e.g., no Redis or external services required).
When your team prioritizes simplicity and explicit critical sections over advanced features like lease expiration or distributed consensus.
When adopting it, budget for a small migration: the Composer package name changed to roadrunner/lock, so composer.json requirements, lockfile entries, and any pinned version constraints referencing the old name must be updated. Treat this as a breaking change for dependency management even if the API surface is unchanged.
Look elsewhere if: using non-RoadRunner environments (e.g., Swoole, traditional PHP-FPM), requiring complex lock semantics (e.g., time-bound leases), running RoadRunner v2 with no near-term upgrade path (stay on 1.1.x), or if your workload has no concurrency risks (e.g., single-process apps).

Executives: "This package ensures our system handles high-traffic scenarios without data corruption or downtime—directly protecting revenue-critical operations like payments or inventory management. The new release keeps us current with RoadRunner v3 and moves locking to a first-party, officially maintained component, which lowers long-term support risk and avoids costly custom solutions. The upgrade is a dependency rename plus a version bump, not a rewrite—small cost, improved reliability and a clear upgrade path at scale."
Engineering: "Version 1.2.0 renames the package to roadrunner/lock and adds RoadRunner v3 support. Practically: update the Composer requirement to the new package name, bump to ^1.2, and confirm the runtime is on RR v3 (v2 users should stay on 1.1.x). The mutex API and zero-configuration usage model are unchanged, so existing critical sections should keep working—just re-run your concurrency tests against the v3 worker lifecycle before rolling out. This is the version to standardize on for any new concurrency-heavy services."