Cache lock refresh() for long-running operations #52778

justinas55 · 2024-09-13T06:12:02Z

justinas55
Sep 13, 2024

Hello,

It would be nice to have a refresh() method on Cache lock instance, that would refresh lock TTL without releasing the lock. This would allow safe long-running operations without compromising with excessive TTL.
As an example such feature is implemented and documented in Symfony: https://symfony.com/doc/current/components/lock.html#expiring-locks .

Currently the closest workaround I found is this:

$lock = Cache::lock('test', 30);
try {
  if(!$lock->get()) {
    throw ...
  }

  $lockStart = time();

  while(!$finished) {
    if(time() - $lockStart > 15) {
       $lock->release();
       // non-atomic - another operation may acquire the lock here, and this instance then must stop/error out depending on specific case
       if(!$lock->get()) {
         throw ...
       }

       $lockStart = time();
    }

   // do actual processing
  }
} finally {
  $lock->release();
}

Having ->refresh(), same code could be simplified and made reliable:

$lock = Cache::lock('test', 30);
try {
  if(!$lock->get()) {
    throw ...
  }

  while(!$finished) {
    $lock->refresh();

   // do actual processing
  }
} finally {
  $lock->release();
}

Haven't found related issues, curious if this has been considered, is there known limitations to implementing this? Should be possible with Redis, probably utilizing transactions, but not sure about the other stores.

Thanks for checking!

ringform · 2025-12-31T22:50:43Z

ringform
Dec 31, 2025

I agree. In the case of long-running operations that take an unpredictable amount of time to finish (e.g. making third-party API requests), the lack of a refresh() function seems to defeat the purpose of acquiring cache locks to prevent race conditions in the first place.

If the cache lock TTL can't be changed and the operation exceeds that time, race conditions can occur. Therefore, for any non-trivial, long-running operation, using the current cache lock implementation is risky.

Further, the language in the Atomic Locks documentation is misleading in this case:

Atomic locks allow for the manipulation of distributed locks without worrying about race conditions.

3 replies

ringform Jan 2, 2026

I wrote a quick and dirty refresh lock function for Redis that works around the current limitations of the framework. It relies on closure binding to get some protected property values but I don't think the names of those properties are likely to change any time soon. And even if they do, errors are logged and the function can be updated at that point. The LUA script is used to prevent race conditions between when the cache lock key is read and when its expiration time is updated.

use Illuminate\Contracts\Cache\Lock;
use Illuminate\Support\Facades\Log;

function refreshRedisLock(Lock $lock): bool
{
    $extract = \Closure::bind(function () {
        return [
            'redis'   => $this->redis   ?? null,
            'name'    => $this->name    ?? null,
            'owner'   => $this->owner   ?? null,
            'seconds' => $this->seconds ?? null,
        ];
    }, $lock, get_class($lock));

    $data = $extra
10BC0
ct();

    foreach ($data as $key => $value) {
        if ($value === null) {
            Log::error("Unable to refresh Redis lock - {$key} is missing.");
            return false;
        }
    }

    $client = $data['redis']->client();

    $script = <<<'LUA'
        local name    = tostring(KEYS[1])
        local owner   = tostring(ARGV[1])
        local seconds = tonumber(ARGV[2])

        if redis.call("GET", name) == owner then
            return redis.call("EXPIRE", name, seconds)
        end

        return 0
    LUA;

    return (bool) $client->eval(
        $script,
        [$data['name'], $data['owner'], $data['seconds']],
        1
    );
}

Use like so:

use Illuminate\Support\Facades\Cache;
use Illuminate\Support\Facades\Log;
use Illuminate\Support\Facades\Redis;

$lock = Cache::lock('foo', 60);

if ($lock->get()) {
    sleep(3);

    $value = Redis::connection('default')->ttl('foo');
    Log::info('Old TTL: ' . $value);

    $refresh = refreshRedisLock($lock);
    Log::info($refresh ? 'Lock refreshed' : "Couldn't refresh lock");

    $value = Redis::connection('default')->ttl('foo');
    Log::info('New TTL: ' . $value);
}

Note: the function must be used inside if ($lock->get()) { ... } (as intended by the framework), otherwise it won't be able to read the cache lock key since it isn't created yet.

For debugging purposes, I found this command to be helpful since it allows you to see the order in which the framework, the refreshRedisLock function, and their associated LUA scripts make updates:

redis-cli -a your_password MONITOR | grep name_of_cache_lock_key

Edit: switched from reflection to closure binding for shorter code thanks to tip from @marius-ciclistu.

marius-ciclistu Jan 2, 2026

Closure binding is shorter as code and has the same outcone.

ringform Jan 2, 2026

@marius-ciclistu Good tip; I updated my code. Hadn't heard of closure binding (1, 2, 3) before.

macropay-solutions · 2026-01-01T23:31:30Z

Cache lock refresh() for long-running operations #52778

Uh oh!

Replies: 2 comments · 12 replies

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Replies: 2 comments 12 replies