Hey - anyone got an example handy of using cfdistributedlock in cfscript for the redis extension? I have the redis extension hooked up to default Object cache. Gpt game me this.. which doesn't look convincing. thanks.

// Create a Redis client object
redis = createObject("java", "redis.clients.jedis.Jedis").init("localhost")

// Define the key and value to be written to the Redis cache
key = "myKey"
value = "myValue"

// Acquire a distributed lock for the key
lockName = "redis_lock_" & key
lockTimeout = 5000 // Lock timeout in milliseconds
lock = cfdistributedlock.acquire(lockName, lockTimeout)

// If the lock is acquired successfully, write the value to the Redis cache
if (lock.isAcquired()) {
    redis.set(key, value)
    
    // Release the lock
    lock.release()
} else {
    writeOutput("Failed to acquire lock for key: " & key)
}

Yea I dont see anything even in the tests for this written in script. Are you receiving an error? I would guess @zackster can point you to a good example.

Thanks. Found some tests - https://github.com/lucee/extension-redis/blob/e87e8c8f0208b4ac8b68fa5d53a2ee22edc62131/tests/DistributedLockTest.cfc#L4 Assuming that it is just something like

DistributedLock name=name cache=cacheName expires=1 timeout=5 {
    cachePut(key, data);
}

will test it out shortly

are you using the latest version?

I am on 3.0.0.48 of the extension (latest) (Lucee 5.3.10.120). I guess it could be an issue with the redis server, which is Redis Stack 6.27

doesn't look like? doesn't mean it's not working, i think the underlying code checks for a lock and if it's expired next time round?

I think your extension code is working ok. I ran code with 2 calls after each other and they both execute the update - even though the lock entry is there in the redis visualizer. It just seemed odd that my visualizer had a ton of open lock entries that never seem to go away - but then again they are tiny,

I know it's being used in anger at scale, i think the idea about them not expiring is so you can always see the last status of the lock, but @micha would need to confirm

if i debug my code and break on the update that is within the di-lo, i do briefly see the di-lo close list entry with a TTL, so what you suggested makes sense.