From bebcc58191dd515e5590bf8c887d53c3a7ed7421 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Deruss=C3=A9?= Date: Mon, 28 Sep 2020 15:47:15 +0200 Subject: [PATCH] Add documentation about fallback logic in lock --- components/lock.rst | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/components/lock.rst b/components/lock.rst index c0f20586e6d..245aaa1de65 100644 --- a/components/lock.rst +++ b/components/lock.rst @@ -90,6 +90,18 @@ they can be decorated with the ``RetryTillSaveStore`` class:: $lock = $factory->createLock('notification-flush'); $lock->acquire(true); +When the provided store does not implements the +:class:`Symfony\\Component\\Lock\\BlockingStoreInterface` interface, the +``Lock`` class will try in a loop to acquire the lock in a non-blocking way +until the lock is acquired. + +.. deprecated:: 5.2 + + As of Symfony 5.2, you don't need anymore using the ``RetryTillSaveStore`` + class. The ``Lock`` class now provides the default logic to acquire locks in + blocking mode when the store does not implements the ``BlockingStoreInterface`` + interface. + Expiring Locks -------------- @@ -213,6 +225,11 @@ possible to **promote** the lock, and change it to write lock, by calling the In the same way, it's possible to **demote** a write lock, and change it to a read-only lock by calling the ``acquireRead()`` method. +When the provided store does not implements the +:class:`Symfony\\Component\\Lock\\SharedLockStoreInterface` interface, the +``Lock`` class will fallback to a write lock by calling the ``acquire()`` +method. + The Owner of The Lock ---------------------