Weave Code
Locking Bundle Laravel Package
integrated/locking-bundle
A PHP package that integrates locking capabilities into your application, helping coordinate concurrent operations and protect shared resources. It provides a straightforward way to manage locks, reducing race conditions and supporting safer background jobs, commands, and workflows.
Provides an interface to manage database locks and keep a lock active by Ajax request
Frequently asked questions about Locking Bundle
- Does integrated/locking-bundle work with Laravel out of the box?
- No. The package is published as a Symfony bundle with DI and event-dispatcher conventions, and there is no evidence of a Laravel service provider, facade, configuration publish command, or version support matrix. Making it work in Laravel means writing an adapter around the Symfony container and event dispatcher, which carries low confidence and recurring maintenance friction. For a Laravel codebase the more realistic option is to reimplement the pattern natively rather than composer require the bundle.
- How do I install integrated/locking-bundle?
- You install it with Composer using the integrated/locking-bundle package name and then register the bundle in a Symfony application's kernel or bundles configuration. There is no documented Laravel installation path, no auto-discovery story for Laravel, and no config file to publish. If you are evaluating this for a Laravel app, treat installation as a scoped spike rather than a routine dependency addition.
- Which lock drivers does the package support?
- The package advertises pluggable lock drivers for database, Redis, and file storage behind a single consistent API. That abstraction layer is the genuinely useful part, because it lets you swap the storage backend without changing the calling code. What the documentation does not settle is which database primitives are used, since GET_LOCK, advisory locks, and SELECT FOR UPDATE behave very differently under connection pooling and long-running workers.
- Does it support blocking lock acquisition with a timeout?
- Yes. The API supports both blocking and non-blocking acquisition with configurable timeouts, along with exception-safe helpers for wrapping critical sections of code. That covers the two common calling patterns: wait briefly for a lock on a hot path, or fail fast and surface a conflict to the user. You should still define in your own code what happens when the timeout expires, since the package cannot decide whether your write path fails open or fails closed.
- How does the package prevent stale locks after a crash?
- The overview states that locks are released automatically on shutdown to prevent stale locks. That handles graceful termination, but it does not cover a hard crash, a killed worker, or a request that dies mid-transaction. Before relying on it you need a defined TTL and a reclamation strategy for orphaned locks, plus a decision on how clock skew between application servers affects expiry.
- Is integrated/locking-bundle production-ready and actively maintained?
- The maturity signals are weak: zero stars, zero dependents, and no visible CI pipeline, changelog, test suite, or security policy. It is effectively a single-vendor artifact published to Packagist. The MIT license makes forking legal, but adopting it in production makes your team the maintainer. That risk profile is driven by project signals rather than by the difficulty of the locking domain itself.
- How does it compare to Laravel's Cache::lock() for pessimistic locking?
- Laravel's built-in Cache::lock() already provides atomic locks across Redis, database, file, DynamoDB, and array drivers, with blocking acquisition, timeouts, and owner tokens. Roughly seventy percent of what this bundle demonstrates, including the lock store and lock service layers, can be reproduced idiomatically on that foundation plus database transactions. What the bundle adds is the design contract around checkout locks and heartbeats, and that is the part worth borrowing rather than the code.
- Which PHP and Laravel versions are supported?
- There is no published version support matrix, and the Symfony packaging suggests Laravel support is not a first-class concern. This is a blocking question for any integration estimate, because you cannot size the work without knowing the PHP constraint and whether modern Laravel releases are even reachable through the Symfony bridge. Get an explicit answer before committing engineering capacity.
- How does the heartbeat and checkout lock pattern work for concurrent edits?
- The design uses pessimistic checkout locks with an Ajax heartbeat that keeps a lock alive while a user has a form open, following an acquire, heartbeat, release-or-expire lifecycle. It slots into a layered application as a lock store, a lock service, an HTTP endpoint, a client-side heartbeat, and enforcement on the write path. Two things must be verified before trusting it: that the heartbeat endpoint authorizes the caller rather than letting any authenticated user refresh or release someone else's lock, and that the save path fails closed to a conflict response when the heartbeat is lost.
- What is the recommended migration path if we already use optimistic concurrency?
- Do not replace your existing concurrency control. Most applications already have optimistic checks such as updated_at comparisons or version columns, so layer pessimistic edit locks in front of them and keep the optimistic check as the source of truth. That way a lost heartbeat degrades into a save conflict instead of silent data loss, and you retain a clean rollback story. Scope the work as a one-week spike with a named owner rather than as a dependency adoption ticket.
Weaver
How can I help you explore Laravel packages today?