Concurrency And Long-Running Process Caveats

Concurrency means more than one piece of work can be in progress at the same time. In PHP, that might be multiple PHP-FPM workers handling requests, multiple queue workers processing jobs, or a long-running runtime handling many requests in one process.

Long-running processes are useful, but they remove the comfort of a clean request ending quickly. You must think about duplicated work, shared state, memory, locks, stale connections, and graceful shutdown.

Duplicate work

If two workers can process the same logical action, the action should be idempotent or protected by a lock.

<?php

declare(strict_types=1);

final class ProcessedJobs
{
    /** @var array<string, true> */
    private array $seen = [];

    public function markIfNew(string $jobId): bool
    {
        if (isset($this->seen[$jobId])) {
            return false;
        }

        $this->seen[$jobId] = true;

        return true;
    }
}

$processed = new ProcessedJobs();

foreach (['email-100', 'email-100'] as $jobId) {
    echo $jobId . ': ' . ($processed->markIfNew($jobId) ? 'process' : 'skip duplicate') . PHP_EOL;
}

// Prints:
// email-100: process
// email-100: skip duplicate

This in-memory example explains the idea. In real applications, idempotency is usually enforced with a database unique key, queue visibility rules, distributed lock, or an external idempotency key.

Shared state

Shared mutable state is dangerous when several requests or jobs can touch it. Files, caches, database rows, static properties, and external APIs can all become coordination points.

Use database transactions, unique constraints, atomic cache operations, queue semantics, or lock services when correctness depends on one worker winning. Avoid "check then write" logic that assumes no other worker can change the value between the check and the write.

Long-running process hygiene

Long-running PHP processes should:

• clear per-job and per-request variables
• avoid storing unbounded data in arrays or static properties
• close or refresh stale database and HTTP connections
• catch errors around each job so one failure does not kill the whole loop unexpectedly
• periodically report memory and health metrics
• stop gracefully when the process receives a shutdown signal
• restart after a safe number of jobs or a memory threshold when appropriate

<?php

declare(strict_types=1);

foreach (range(1, 3) as $jobNumber) {
    echo 'Processing job ' . $jobNumber . PHP_EOL;

    gc_collect_cycles();
}

echo 'Worker can shut down cleanly.' . PHP_EOL;

// Prints:
// Processing job 1
// Processing job 2
// Processing job 3
// Worker can shut down cleanly.

This is a toy loop, but the shape is common: process one unit of work, clean up, then continue or exit safely.

Deployments and old code

Long-running workers do not automatically use new code just because files changed on disk. A deploy should restart or reload workers so the new code, configuration, and dependencies are actually loaded.

This applies to queue workers, RoadRunner workers, Octane workers, FrankenPHP worker mode, Swoole/OpenSwoole servers, and custom daemons.

What you should be able to do

After this lesson, you should be able to explain why duplicate work happens, identify where idempotency or locking is needed, review long-running worker hygiene, and understand why deployments must restart persistent PHP processes.