Weave Code
Advisory Locker Laravel Package
fervo/advisory-locker
A lightweight Laravel package for storing and managing advisory records locally. Advisory Locker offers a simple, cache-friendly way to keep dependency and security advisories organized so your app can query them quickly without repeated external lookups.
A PHP library to acquire advisory locks from your Doctrine database
Frequently asked questions about Advisory Locker
- What is fervo/advisory-locker used for?
- It lets a Laravel application acquire, release, and check database advisory locks so separate processes and servers can coordinate around a critical section. Typical uses are preventing overlapping scheduled jobs, ensuring only one queue worker handles a given task, and guarding code that must not run concurrently. It relies on PostgreSQL pg_advisory_lock and MySQL GET_LOCK through Doctrine DBAL, so no Redis or dedicated lock service is required. The package describes a fluent API, closure-based locking with automatic release, and configurable wait timeouts.
- Does fervo/advisory-locker work with Laravel's normal DB facade or Eloquent?
- No, it is a thin abstraction over Doctrine DBAL rather than Laravel's DB facade or Eloquent. In an Eloquent-first application you have to create or bind a DBAL connection and pass it to the library, which is the main integration cost. If your app already uses Doctrine DBAL or ORM, the fit is much better. For a purely Eloquent codebase, wrapping a direct DB::selectOne call is usually simpler than adopting the package.
- Which Laravel and PHP versions does fervo/advisory-locker support?
- The last release was 2021-10-06, so there is no evidence of testing against current Laravel or PHP versions. Treat advertised version constraints as a starting point and run composer why-not before committing. Dormant packages often resolve on older Laravel releases but conflict with modern dependency trees. Verify on a throwaway branch with your exact framework and database versions.
- Does it require doctrine/dbal, and which major version?
- Yes, it is built on Doctrine DBAL because that is where the PostgreSQL and MySQL advisory-lock drivers live. A 2021-era DBAL wrapper plausibly pins doctrine/dbal ^2.x, which can conflict with the 3.x or 4.x versions required by modern Doctrine bundles. Run composer require fervo/advisory-locker --dry-run or composer why-not doctrine/dbal to see the real constraint. If Composer forces a downgrade, integration effectively becomes a fork.
- How do I install and configure it in a Laravel app?
- Install with composer require fervo/advisory-locker, then bind a DBAL connection and configure the driver and connection settings the package expects. Mechanically the integration is a service-provider binding, a driver config entry, and a try/finally around the critical section that releases the lock. Because the package is dormant, confirm that service provider registration, config publishing, and connection resolution still work on your Laravel version before relying on it.
- Are the advisory locks session-scoped or transaction-scoped?
- They are session-scoped: the lock belongs to the database connection and remains held until it is explicitly released or the connection ends. PostgreSQL's pg_advisory_xact_lock is transaction-scoped and is often safer for short web requests because the lock is released automatically at commit or rollback. The package's abstraction hides this detail, so confirm which behavior your driver path uses. Always release locks in a finally block.
- Can I acquire a lock without blocking forever?
- The package advertises configurable wait timeouts and blocking behavior, so a timeout-bounded acquire should be available. On PostgreSQL the underlying non-blocking primitive is pg_try_advisory_lock, while MySQL uses GET_LOCK with a timeout value. Make sure the configured timeout is shorter than your job or request timeout so a worker cannot hang indefinitely. A non-blocking attempt is usually the right default in web request paths.
- What happens if the connection drops while the lock is held?
- Because advisory locks are tied to the database session, a dropped connection normally releases the lock when the server notices the session ended. That prevents a permanent leak, but it also means the critical section may have been interrupted, so the next run can repeat work. Design the guarded operation to be idempotent and monitor for failures rather than assuming the lock guarantees completion. The package description does not mention lock-leak detection or recovery handling.
- Is it safe with PgBouncer, RDS Proxy, read/write splitting, or Laravel Octane?
- This is the highest-risk area. PgBouncer in transaction pooling mode and similar proxies can break session-scoped advisory locks by moving or ending sessions, and Octane's reused workers can hold a lock across unrelated requests if it is not released. Use a direct or session-pooled connection for locking, or a dedicated connection, and release explicitly in finally. An abstraction layer hides exactly the connection topology details you need to reason about here.
- Is fervo/advisory-locker maintained, and what are the alternatives?
- It is effectively dormant: 1 star, 0 dependents, and a last release of 2021-10-06, with no public issue history or evidence of tests against current databases. For most Laravel teams the safer path is a small first-party lock helper using DB::selectOne('SELECT pg_try_advisory_lock(?)', [$key]) or the MySQL GET_LOCK equivalent, which is roughly a day of work and makes session scoping explicit. Laravel's Cache::lock with Redis or the database driver, or queue job uniqueness, are alternative coordination options if you can accept their trade-offs.
Weaver
How can I help you explore Laravel packages today?