The issue is that doctrine is keeping the objects in local memory because the daemon is basically a php long-running process. In order to allow the objects used by the job to get updated, you need to $em->detach() the objects. But you'd also have to have cacade={"detach"} on all relationships that object has as well. So the best thing is to just call $em->clear() at the end of your job. This will detach all objects from doctrine and it will get a fresh copy of all the objects from the database for the next job run.

With long running processes you can get a 2006 MySQL server has gone away error. This adds a class that calls Doctrine's DBAL Connection's $conn->ping() to see if it's gone away, if so close the connection and let DBAL automatically open a new connection on the next query attempt. This is talked about in the Doctrine's Github repo here. Here's some pseudo code on how to do it:

<?php

namespace Acme\Doctrine\ORM;

use Doctrine\ORM\EntityManager;

class ConnectionSaver
{
    /**
     * Ping the DB server, if connection is lost close it and DBAL will
     * automatically reconnect on the next DB call.
     */
    public function checkDatabaseConnection()
    {
        /** @var \Doctrine\DBAL\Connection */
        $conn = app(EntityManager::class)->getConnection();

        try {
            $ping = $conn->ping();
        } catch (\ErrorException $e) {
            $conn->close();
        }
    }
}

Then inside the command handler you just inject the class and call checkDatabaseConnection() function.

<?php

namespace App\Listeners\Commands;

use Acme\Doctrine\ORM\ConnectionSaver;

class FooHandler
{
    public function __construct(ConnectionSaver $connectionSaver) {
        $connectionSaver->checkDatabaseConnection();
    }

#orms were first created by Richard Stallman, what did you think the "RMS" stood for? #doctrine #eloquent #propel

Interesting presentation from one of the Doctrine core team members.

In this Talk, we are going to dive into Doctrine 2 ORM’s feature set. We’re going to see the advantages and disadvantages of each functionality, with a particular focus on use-cases that each functionality attempts to solve, which features should be used with care (or avoided completely) and which ones should be used even more.

Several php packages to easily integrate Doctrine 2 into your next Laravel/Lumen project. The 'orm' package includes a ServiceProvider to add Doctrine to your project and configure it. The 'extensions' package includes several extensions including timestampable, softdeletable, etc. The 'migrations' package add ability to use Doctrine's migration package instead of laravel's migrations so that you can easily take advantage of auto migration generation based on entities. The 'ACL' package includes traits to add roles and permissions to user objects to easily integrate with Laravel's new ACL.

Doctine requires a custom made cli-config.php file for Setting up the Commandline Tool with a Laravel 5 application. The CLI tool is necessary when you need to for example clear Doctrine Cache using php vendor/bin/doctrine orm:clear-cache:metadata.

The following is what you can put in your cli-config.php:

<?php

use Doctrine\ORM\EntityManager;
use Doctrine\ORM\Tools\Console\ConsoleRunner;

// replace with file to your own project bootstrap
/** @var Illuminate\Foundation\Application $app */
$app = require_once __DIR__ . '/bootstrap/app.php';

/** @var Illuminate\Contracts\Console\Kernel $kernel */
$kernel = $app->make('Illuminate\Contracts\Console\Kernel');
$kernel->bootstrap();

$app->boot();

// replace with mechanism to retrieve EntityManager in your app
$entityManager = $app[EntityManager::class];

return ConsoleRunner::createHelperSet($entityManager);

Note you will need to have already registered the EntityManager with your app through a service provider. You can use a package like mitchellvanw/laravel-doctrine or opensolutions/doctrine2bridge-l5 to setup Doctrine in Laravel 5.