mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
How to check for unusable entity manager? #5366
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @andig on GitHub (Dec 28, 2016).
I'm working on making my application persistent using PHP-PM for performance reasons. This requires- as
EntityManagermay become closed to check if it needs being reset. I'm currently doing it like this:The
ping()was added when I became aware that mysql error 2006 (server gone away) does cause exceptions but does not force theEntityManagerto close.Wondering if a)
EntityManagershould also close in this case or b) what other reasons there could be for an open yet unusableEntityManager?@Ocramius commented on GitHub (Dec 28, 2016):
There's no real way to close an entity manager from a closed connection, since the connection holds no reference to the EM.
What could be done (unsure) is using
Doctrine\DBAL\Connection#ping()in aDoctrine\ORM\EntityManagerInterface#isOpen()call, and close it if it doesn't respond@Jean85 commented on GitHub (Dec 29, 2016):
Can I shamelessly plug our package here? :)
https://github.com/facile-it/doctrine-mysql-come-back
This recovers from MySQL server gone away errors.
Also, replying here to keep track of this issue, so we avoid BC in our package.
@andig commented on GitHub (Dec 29, 2016):
I wasn't implying that. Rather I was assuming that the connection error occurs during an ORM operation and should therefore close the entity manager. If that actually is the expected behavior then I could offer to do some instrumentation to find out if the closing really is encountered during ORM operation or when my app is directly using DBAL for some specifiy tasks.
Which is basically what I've done, in my case at the beginning of an http request instead of inside the entity manager.
@Jean85 thank you for the suggestion- will look into it.
@stof commented on GitHub (Jan 3, 2017):
@andig but the server might have gone away after the last ORM operation. So the next operation would break and close the EM, but it is not closed yet
@andig commented on GitHub (Jan 3, 2017):
@stof good catch, thank you, that explains it. Since the application is long-running thanks PHP-PM that's exactly whats happening. Please feel free to close if this is too specific for an improvement.