Advisory Locker Laravel Package

Product Decisions This Supports

• Build vs. buy for mutual exclusion. Advisory locks are the "use the database you already have" answer to a recurring product need: preventing duplicate work. This package is the cheapest possible probe of that decision — it tells you whether Postgres-native locking is sufficient before you budget for Redis, a managed lock service, or a queue redesign.
• De-duplicating scheduled and queued work. Overlapping cron jobs, double-dispatched jobs, and duplicate webhook processing are the classic source of "why did the customer get two emails / two charges." If the team keeps filing these as bugs, a DB-backed lock is a product-level fix, not just an infra one.
• Idempotency in user-facing flows. Payment capture, invoice generation, report exports, and subscription state transitions all benefit from a named lock keyed on business identity (e.g. invoice:{id}). This supports reliability commitments on the roadmap without a new vendor contract.
• Migration and deploy safety. Wrapping schema migrations and one-off backfills in a lock lets you ship multi-instance deploys and rolling releases without a "who runs the migration" runbook step — a direct buy-back of engineering time on release cadence.
• Backlog triage / make-vs-maintain. With 1 star, 0 dependents, and a last release of October 2021, the realistic decision this package informs is "do we adopt it, vendor it, or write 100 lines ourselves?" — a low-stakes call you can settle in an afternoon rather than an architecture review.
• Platform scope decision. Despite the "Laravel integration" framing in its description, the underlying library is Doctrine DBAL-shaped. Adopting it implicitly asks whether an Eloquent-first codebase will accept a Doctrine dependency just for locking. That's a real, if small, signal about how much polyglot plumbing the team is willing to carry.

When to Consider This Package

Reasonable to consider when:

• Your primary datastore is PostgreSQL (or MySQL, if you accept GET_LOCK semantics) and the team has explicitly decided not to add Redis or another lock service for this class of problem.
• The workload is low-frequency, coarse-grained mutual exclusion — nightly jobs, one-per-tenant backfills, deploy-time migrations, single-flight cache refreshes. Tens of locks per minute, not thousands per second.
• You already run Doctrine DBAL somewhere in the stack, so the dependency is not purely additive.
• You need lock semantics tied to transaction or session scope, where "the lock dies when the connection dies" is a feature rather than a hazard.
• You are evaluating the pattern rather than the artifact: the library is small enough to read in one sitting and treat as a reference implementation to vendor internally, with an owner, tests, and a pinned version.

Look elsewhere when:

• You need a maintained dependency. No release since October 2021, 1 star, 0 dependents means no security response, no PHP-version guarantee, and no community to absorb upgrade work. On a critical path, prefer illuminate/cache locks or a Redis-backed implementation your team already operates and monitors.
• You run PgBouncer in transaction pooling mode, or Laravel Octane / long-lived workers. Advisory locks are session-scoped; a pooled or reused connection can hold a lock across unrelated requests or drop it mid-operation. This is the single biggest correctness trap and the package cannot solve it for you.
• Your primary database is not Postgres/MySQL. SQLite, SQL Server, or a multi-engine deployment has no portable advisory-lock story.
• You need observability, TTLs, fencing tokens, or blocking-with-timeout ergonomics. Contention metrics, alerting on held locks, and safe retry policies are out of scope.
• You are a pure Laravel/Eloquent stack with no Doctrine. Adding DBAL just for locking is a poor trade against Cache::lock(), which the team already knows and which works against Redis, Memcached, DynamoDB, or the database.
• You have high-contention hot keys. Advisory locks serialize hard; a heavily contested lock is a queue with worse ergonomics.

How to Pitch It (Stakeholders)

For executives — one paragraph: We have a recurring class of reliability defects where two workers do the same job at the same time — duplicate emails, double-charged invoices, overlapping nightly jobs, migration races during deploys. The conventional fix is new infrastructure (Redis or a managed lock service) with its own cost, on-call surface, and vendor relationship. Advisory locks solve the same problem using the database we already run, with no new vendor and no new operational burden. This particular package is a small, unmaintained open-source helper for that technique: the technique is worth adopting; the package is worth roughly a day of evaluation and, if we proceed, an internal fork we own. Recommendation: fund a one-week spike to prototype DB-backed locking on two concrete flows (nightly job overlap and invoice generation), measure it against Cache::lock(), and only then decide whether to standardize or buy a managed service.

For engineering — the honest summary: The artifact is thin: Doctrine DBAL advisory locks over PostgreSQL pg_advisory_lock / MySQL GET_LOCK, last released 2021-10-06, 1 star, 0 dependents, no cadence we can rely on. Despite the "lightweight Laravel integration" description, it expects a Doctrine connection, which an Eloquent-first app does not have — so adoption likely means either a second connection pool (a real hazard for session-scoped locks) or a fork. Treat it as a ~100–150 line reference implementation, not a dependency. If we adopt the pattern, we own it: pin a fork into app/Support behind a first-party LockManager interface, add tests for acquire/release/timeout, bind a single connection identity, and document the lifecycle constraint loudly — session-scoped locks plus PgBouncer transaction pooling or Octane's reused connections will produce silent correctness bugs that pass in CI and fail in production. Before adding Doctrine to a Laravel service, benchmark against Cache::lock() (already available, provider-agnostic, has block() and TTL semantics). The decision to make this week is which lock primitive we standardize on, not whether to install this package.