Doctrine2 timeout de connexion dans daemon

J'ai une longue course démon (Symfony2 Commande) qui vient compenser une file d'attente de travail dans le Redis, et effectue ces travaux et des écritures dans la base de données à l'aide de l'orm.

J'ai remarqué que dès qu'il ya une tendance pour les travailleurs de mourir parce que la connexion à MySQL expiré lorsque le travailleur est au ralenti en attente pour le travail.

Plus précisément, je vois cela dans le journal: MySQL Server has gone away.

Est-il de toute façon je peux avoir doctrine reconnecter automatiquement? Ou est-il une manière que je peux manuellement intercepter l'exception et la reconnexion de l'orm doctrine?

Grâce

source d'informationauteur James Cowhen

  1. 22

    J'utilise dans mon symfony2 beanstalkd démon de Commande travailleur:

    $em = $this->getContainer()->get('doctrine')->getManager();
if ($em->getConnection()->ping() === false) {
    $em->getConnection()->close();
    $em->getConnection()->connect();
}
  2. 11

    Il semble que chaque fois qu'il y a une erreur/exception rencontrées par l'EntityManager dans la Doctrine, la connexion est fermée et l'EntityManager est mort.

    Depuis généralement, tout est enveloppé dans une transaction et que cette transaction est exécutée lorsque $entityManager->flush() est appelée, vous pouvez essayer de l'attraper l'exception et de tenter de ré-exécuter ou à l'abandonner.

    Vous souhaitera peut-être examiner la nature exacte de l'exception avec plus de prises précis sur le type, si PDOException ou quelque chose d'autre.

    Pour un MySQL a Disparu exception, vous pouvez essayer de se reconnecter par la réinitialisation de l'EntityManager.

    $managerRegistry = $this->getContainer()->get('doctrine');
$em = $managerRegistry->getEntityManager();
$managerRegistry->resetEntityManager();

    Cela devrait faire l' $em utilisable à nouveau. Notez que vous devrez ré-persistent tout nouveau, puisque c' $em est nouveau.

  3. 7

    J'ai eu le même problème avec un PHP Gearman travailleur et de la Doctrine 2.

    La solution la plus propre que j'ai trouvé: il suffit de fermer et de rouvrir la connexion à chaque emploi:

    <?php
public function doWork($job){
   /* @var $em \Doctrine\ORM\EntityManager */
   $em = Zend_Registry::getInstance()->entitymanager;
   $em->getConnection()->close();
   $em->getConnection()->connect();
}

    Mise à jour

    La solution ci-dessus n'a pas à composer avec le statut de la transaction. Cela signifie que la Doctrine\DBAL\Connection::close() la méthode n'est pas réinitialisé le $_transactionNestingLevel valeur, donc si vous n'avez pas valider une transaction, qui conduira à la Doctrine de ne pas être dans la synchro sur le statut de la traduction avec le SGBD sous-jacent. Cela pourrait conduire à la Doctrine qui consiste à ignorer begin/commit/rollback états et, éventuellement, les données n'étant pas engagé au SGBD.

    En d'autres termes: assurez-vous de commit/rollback des transactions si vous utilisez cette méthode.

  4. 5

    Ce avec ce wrapper il a travaillé pour moi:

    https://github.com/doctrine/dbal/issues/1454

  5. 2

    Dans votre démon vous pouvez ajouter une méthode pour redémarrer la connexion peut-être avant chaque requête. Je faisais face à des problmes similaires à l'aide de gaerman travailleur:

    Je me garder les données de connexion dans zend de registre de sorte qu'il ressemble à ceci:

    private function resetDoctrineConnection() {
    $doctrineManager = Doctrine_Manager::getInstance();
    $doctrineManager->reset();
    $dsn = Zend_Registry::get('dsn');
    $manager = Doctrine_Manager::getInstance();
    $manager->setAttribute(Doctrine_Core::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
    Doctrine_Manager::connection($dsn, 'doctrine');
}

    Si c'est damenon vous faut peut-être appeler cela de manière statique.