Weave Code
Doctrine Resettable Em Bundle Laravel Package
pixelfederation/doctrine-resettable-em-bundle
Symfony bundle that provides a resettable Doctrine EntityManager, letting applications recover from closed or failed managers after database exceptions and continue handling requests and background work reliably.
Resettable entity manager for long running apps (swoole, message consumers)
Frequently asked questions about Doctrine Resettable Em Bundle
- Can I use pixelfederation/doctrine-resettable-em-bundle in a Laravel application?
- No, not as a real dependency. It is a Symfony bundle whose service wiring depends on Symfony's DI compiler passes, FrameworkBundle conventions, and the Symfony Messenger middleware interface, none of which exist in Laravel. Laravel's default ORM is Eloquent anyway, so even a laravel-doctrine setup cannot install and enable it meaningfully. The realistic Laravel path is to port the pattern into your own code rather than require the package.
- What does the resettable Doctrine EntityManager bundle actually do?
- It wraps Doctrine ORM's EntityManager in a ResettableEntityManager decorator and resets it at safe boundaries. In practice that means a Symfony Messenger middleware that resets after each handled message and a console event listener that resets after each command run. This prevents a stale identity map or leaked transaction state from corrupting subsequent jobs in long-running processes such as Messenger workers, Swoole, RoadRunner, or queue daemons.
- How do I install and enable this bundle in a Symfony app?
- Run composer require pixelfederation/doctrine-resettable-em-bundle and enable the bundle in your kernel or bundles.php as usual for Symfony. The reset middleware is registered automatically when Symfony Messenger is present, so there is typically no application code to write. Setup effort is measured in minutes, and the only real decision is whether your dependency constraints accept the Symfony versions it supports.
- Does this package work with Laravel Octane or Laravel queue workers?
- Not directly. The bundle hooks into Symfony Messenger middleware and Symfony console events, so it has no awareness of Laravel's queue events or Octane's request lifecycle. To get the same protection in Laravel you would hook into JobProcessed and JobExceptionOccurred, or into Octane's request lifecycle events, and reset your Doctrine EntityManager there yourself. The concept transfers cleanly, but the package does not.
- How would I port the resettable EntityManager pattern to Laravel?
- The pattern is small, roughly 100 to 200 lines. Write a decorator around Doctrine's EntityManager that checks isOpen(), calls clear() or reopens the manager after each unit of work, bind it in a service provider so your repositories resolve the decorated instance, and register a queue event hook that triggers the reset after every job. Mirror the bundle's opinionated choice of resetting after the unit of work completes, never mid-transaction. That combination gives you the same protection without any Symfony coupling.
- Which Symfony and PHP versions does version 11.1.0 support?
- The 11.1.0 release contains exactly one change: broadening compatibility to Symfony 8.1. Because Symfony 8.x implies a recent PHP floor and drops older majors, you should read the composer.json constraints rather than assume support for your current stack. Pulling it into a project whose other bundles are pinned to Symfony 7.x can produce an unsatisfiable dependency graph. Check whether the widened constraint admits dev or RC versions if Symfony 8.1 is not yet a stable line for you.
- Is upgrading from 11.0.0 to 11.1.0 safe?
- Yes, it is a drop-in minor. There are no API changes, no deprecations, and no behavioral changes, only a framework compatibility constraint widening. Because the reset semantics are untouched, any validation you did on 11.0.0 remains valid and no re-certification of reset correctness is needed. The only thing worth confirming is that the new constraint does not break resolution against your other pinned packages.
- Does the bundle clear the EntityManager in the middle of a transaction?
- No. Resets happen at safe boundaries after the unit of work completes, such as after a Messenger message is handled or after a console command finishes. That is deliberate: clearing an EntityManager with an open transaction would detach entities and lose in-flight state. Keep that same discipline if you replicate the behavior elsewhere.
- Is this package actively maintained, and how risky is depending on it?
- It is vendor-maintained by Pixel Federation with a fairly narrow contributor base, and the 11.1.0 changelog is a single PR from a recurring contributor. That is normal for a mature utility bundle, but it does mean the bus factor and the review depth on constraint changes deserve a look before you rely on it in production. The failure mode is also quiet: a broken reset surfaces as cross-request data bleed or detached entity errors hours later under load, so add your own smoke tests around job isolation rather than trusting the release blindly.
- What are the alternatives if I just need to reset Doctrine's EntityManager?
- In Symfony you can rely on DoctrineBundle's ManagerRegistry resetManager() or write a small Messenger middleware of your own that calls clear() when the manager is closed. In Laravel with laravel-doctrine, the equivalent is a custom decorator or middleware that resets the manager after each job, plus DB::reconnect() handling for the underlying connection. For Eloquent-only apps the comparable tools are clearing the model state and reconnecting, which addresses the same long-running process problem from a different angle.
Weaver
How can I help you explore Laravel packages today?