How to check for unusable entity manager? #5366

Open
opened 2026-01-22 15:05:34 +01:00 by admin · 5 comments
Owner

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 EntityManager may become closed to check if it needs being reset. I'm currently doing it like this:

if (null == $this->em || !$this->em->isOpen() || $this->em->getConnection()->ping() === false) {
	$this->em = self::createEntityManager();
}

The ping() was added when I became aware that mysql error 2006 (server gone away) does cause exceptions but does not force the EntityManager to close.

Wondering if a) EntityManager should also close in this case or b) what other reasons there could be for an open yet unusable EntityManager?

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 `EntityManager` may become closed to check if it needs being reset. I'm currently doing it like this: if (null == $this->em || !$this->em->isOpen() || $this->em->getConnection()->ping() === false) { $this->em = self::createEntityManager(); } The `ping()` was added when I became aware that mysql error 2006 (server gone away) does cause exceptions but does not force the `EntityManager` to close. Wondering if a) `EntityManager` should also close in this case or b) what other reasons there could be for an open yet unusable `EntityManager`?
admin added the Improvement label 2026-01-22 15:05:34 +01:00
Author
Owner

@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 a Doctrine\ORM\EntityManagerInterface#isOpen() call, and close it if it doesn't respond

@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()`](https://github.com/doctrine/dbal/blob/b551fcb26a81e230085c0dca88174573b6c36609/lib/Doctrine/DBAL/Connection.php#L1575) in a [`Doctrine\ORM\EntityManagerInterface#isOpen()`](https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/EntityManagerInterface.php#L235) call, and close it if it doesn't respond
Author
Owner

@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.

@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.
Author
Owner

@andig commented on GitHub (Dec 29, 2016):

There's no real way to close an entity manager from a closed connection

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.

What could be done (unsure) is using Doctrine\DBAL\Connection#ping() in a Doctrine\ORM\EntityManagerInterface#isOpen() call, and close it if it doesn't respond

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.

@andig commented on GitHub (Dec 29, 2016): > There's no real way to close an entity manager from a closed connection 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. > What could be done (unsure) is using Doctrine\DBAL\Connection#ping() in a Doctrine\ORM\EntityManagerInterface#isOpen() call, and close it if it doesn't respond 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.
Author
Owner

@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

@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
Author
Owner

@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.

@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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: doctrine/archived-orm#5366