Doctrine Entity Lock Bundle Laravel Package

Product Decisions This Supports

• Data-integrity features in contested flows. The capability here is entity-level locking (optimistic/pessimistic) on top of Doctrine, which is what prevents double-booking, oversold inventory, lost updates on ledgers/balances, and conflicting workflow state transitions — correctness work, not polish.
• Build vs buy on locking. The realistic alternatives are hand-rolled version columns, SELECT ... FOR UPDATE in repositories, database advisory locks, or a distributed lock service (Redis, etc.). This package is thin configuration glue over Doctrine's lock modes, so the "buy" case rests on reduced bespoke code and consistent conventions, not on novel capability. Weigh it as a small integration cost against ongoing maintenance of in-house locking utilities.
• Stack-scoping decision. Despite the Laravel/PHP framing in the request, this is a Doctrine bundle — the natural home is Symfony + Doctrine ORM. That makes adoption a persistence-layer decision before it is a feature decision. If we're on Laravel/Eloquent, the answer is Laravel's lockForUpdate()/sharedLock() inside transactions, not this.
• Roadmap signal from 1.0.1: none. The release note is a bare changelog compare link with no described changes. Treat it as patch-level maintenance noise; it should not move prioritization, and it should not be cited as evidence of project health.
• Concrete use cases to scope against: seat/ticket reservation, stock decrement, account balance mutation, idempotent job claiming, and any read-modify-write on a single entity under contention.

When to Consider This Package

Consider it when:

• We are on Symfony + Doctrine ORM and want locking declared at the entity level rather than scattered across repositories.
• The contention is on individual rows within one database, and per-entity optimistic or pessimistic locking maps cleanly to the domain.
• We want to standardize locking conventions across teams with minimal custom infrastructure.

Look elsewhere when:

• We are on Laravel/Eloquent — the Doctrine dependency is disqualifying, and the native query builder locks cover the common cases.
• Contention spans services, databases, or datastores — use a distributed lock or database advisory locks instead; row locks won't help.
• We need documented BC policy, published changelogs, or evidence of test coverage. A 1.0.x release with an empty note is not a strong maintenance signal.
• Locking needs are trivial — one or two call sites don't justify a dependency.

Due diligence before any adoption decision: confirm active maintenance and release cadence, verify the license, check PHP and Doctrine version constraints against our matrix, and confirm which lock semantics we actually get and how they behave on our engine (MySQL vs PostgreSQL differ materially for FOR UPDATE and advisory locking). Then validate under real concurrency with integration tests — lock bugs do not surface in single-threaded test suites.

How to Pitch It (Stakeholders)

Executives: A small, low-cost library that reduces a class of expensive data-integrity bugs — double charges, oversold stock, silently lost updates — in high-contention flows. The cost is integration effort, not licensing exposure. The catch: it only applies if we're on the Doctrine stack, so this is a narrow bet rather than a broad platform investment.

Engineering: A thin configuration layer over Doctrine entity locking; value is consistency and less bespoke locking code, risk is low but the project is early (1.0.1) with opaque release documentation. Pin the version, and require concurrency tests before relying on it in money-touching paths.

Recommendation: Do not adopt on the basis of 1.0.1 — this release carries no decision-relevant information. Revisit only if we standardize on Doctrine and the package demonstrates a maintenance track record over the next few releases.