[RFC][lock] Introduce Shared Lock (or Read/Write Lock)

[jderusse]

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	/
License	MIT
Doc PR	TODO

This PR adds a new method "acquireRead" to the Lock class in order to solve the single writer multiple readers problem.

usage:

$aliceLock = $factory->createLock('invoice');
$bobLock = $factory->createLock('invoice');
$oscarLock = $factory->createLock('invoice');

$aliceLock->acquireRead(); // true
$bobLock->acquireRead(); // true
$oscarLock->acquire(); // false

next steps

add more stores

• pdo
• memcached
• zookeeper
• mongodb

Priority policies

Priority policy (read-preffering or write preffering) is not covered by this PR.

Promote/Demote

Converting a Read lock to Write Lock (promote) or Write lock to Read lock (demote) is covered by calling acquireRead / acquired method.

// demote
$lock->acquire();
...
$lock->acquireRead(); 

// promote
$lock->acquireRead();
...
$lock->acquire(); 

[stof]

Do stores deal properly with an upgrade scenario, where the store might contain existing locks created using the old format for the state ?

[jderusse]

Do stores deal properly with an upgrade scenario, where the store might contain existing locks created using the old format for the state ?

Good point. For sure, they have to.
But I don't know how to add test to assert it.

[stof]

Good point. For sure, they have to.

I know they have to. The question is whether they actually do.

To test this, we would need to write some lock in the old format in Redis (or whatever storage) and then try to acquire the same lock with the new code and ensure it does not break but properly detects a conflict.

For a local test, what you can do is creating 2 projects: one using symfony/lock 5.1 to acquire the lock and hold it, and another one using your new code and trying to acquire a (conflicting) lock (should be tested with both acquire() and acquireRead(). This might be easier than filling the storage by hand.

[jderusse]

I tested compatibility locally with 2 clients (with different versions) at the same time and it worked in both way.
(tested Flock and Redis)

I also added a integration test that reuse the old code to assert it for Redis.

[fabpot]

@jderusse Just for my information, the next step here is to implement the feature in other stores?

[jderusse]

@jderusse Just for my information, the next step here is to implement the feature in other stores?

That was my first idea. But it's more complicated than I thought, and PR might be harder to review. I suggest:

• decide if we like the idea/rfc and merge this PR first (with 2 stores implemented)
• create 1 PR dedicated per store latter (5.2 if possible)

[fabpot]

Having this feature available for some stores only is fine by me.

[fabpot]

@jderusse Having additionnal stores in other PRs is a good idea. Can you finish this one without other stores?

[jderusse]

TIME is not deterministic before Redis 5.0 (see #35780 (comment))

But using php's time (multiple source/server) is not reliable.

What's the best solution @lyrixx ?

[lyrixx]

In semaphore I used the server's time. I think it's more reliable than hopping user are running redis > 5.X

[jderusse]

Oh, I did not realized that the script of REDIS < 5 was broken because of that.
Thanks for the confirmation, I've refactored this part.

[jderusse]

PR is ready for review, with the current 2 stores (flock, redis)

[jderusse]

This check provide backward compatibility:

• when an old version of symfony put a lock, the new version won't be able to put a lock.

But the opposite is not (always) true:

• with predis: when a new version of symfony put a lock, the old version will fail with an ServerException
• with phpredis it's ok: when an new version of symfony put a lock, the old version won't be able to put a lock.

Both situation are safe (user won't be able to acquire the lock), but the complexity of the code to throw a proper "LockConfictException" instead of "predis\ServerException" don't worth it IMHO

[fabpot]

Thank you @jderusse.