summaryrefslogtreecommitdiff
path: root/redis/lock.py
Commit message (Collapse)AuthorAgeFilesLines
* Lock objects now support specifying token values and ownership checkingAndy McCurdy2019-01-021-2/+24
| | | | | | | | Lock.acquire() can now be provided a token. If provided, this value will be used as the value stored in Redis to hold the lock. Lock.owned() returns a boolean indicating whether the lock is owned by the current instance.
* Add `.reacquire()` method to LockIhor Kalnytskyi2018-12-281-0/+36
| | | | | | | | | | | | `Lock` class provides a method called `.extend()` to manage a TTL of the acquired lock. However, the method allows only to extend a timeout of existing lock by N seconds, there's no way you can reset a TTL to the timeout value you passed to this lock. There could be multiple use cases for such behaviour. For instance, one may want to use a lock to implement active/passive behaviour where only one process owns a lock and resets its TTL all over again until it dies. This commit adds a new method called `.reacquire()` to reset a TTL of the acquired lock back to the passed timeout value.
* rename new LockErrorNotOwned to LockNotOwnedErrorAndy McCurdy2018-12-031-3/+3
|
* Extend lock error for not owned special caseJoshua Harlow2018-12-031-3/+5
| | | | | | | | Using the locking routines, it is useful to be able to distingush a generic lock error from a one that is related to the lock not being owned anymore (without doing string checks); this allows say a lock extension thread to attempt to re-acquire the lock in this case (vs just dying).
* Update .locked() to indicate if lock has been acquired by any procesesAndy McCurdy2018-11-151-2/+4
| | | | | | This make just like threading.Lock objects do. Fixed #1007
* add locked() method to lock objectAndy McCurdy2018-11-141-0/+4
| | | | | | | Lock.locked() returns a boolean indicating if the lock is acquired and valid. Thanks Alan Justino da Silva Fixes #1007
* raise a LockError when the context manager fails to acquire a lockv3-breaking-changesAndy McCurdy2018-11-141-2/+3
| | | | | Fixes #621 Fixes #927
* only support LuaLock going forwardAndy McCurdy2018-11-141-92/+50
| | | | | | | | | | Everyone is using Redis 2.6 or greater, right? The Lua lock implementation is so much nicer and less buggy. Fixes #1031 Fixes #902 Fixes #793 Fixes #610
* Use unicode literals throughout projectJon Dufresne2018-11-031-2/+1
| | | | Remove workaround for handling unicode with older Pythons.
* "while 1" --> "while True"Jeff Widman2018-10-111-1/+1
| | | | This is python, not C
* Removing do_acquire from lualock as there is no gain over default do_acquireRobert Kopaczewski2014-12-111-24/+0
|
* Fix lua lockingRobert Kopaczewski2014-12-101-8/+4
|
* Atomic redis.set when acquiring a lockRobert Kopaczewski2014-12-101-9/+15
|
* Lock.acquire() to respect blocking_timeout argumentGrant Cox2014-06-191-2/+2
|
* more info on thread local storageAndy McCurdy2014-06-161-4/+25
|
* restore default Lock token storage, add toggle to make it thread-localwil paredes2014-06-061-2/+9
| | | | | * add thread_local=False parameter to Lock.__init__() and StrictRedis.lock() * use thread_local to decide whether to put token in thread-local storage
* move Lock.token attribute into thread-local storagewil paredes2014-06-051-8/+10
|
* Lock.release(): reorder code to avoid token overwritewil paredes2014-06-051-9/+7
| | | | | | * assignment to self.token was not protected by the lock, so the value could get overwritten * do_release() now has an expected_token parameter that receives the old token value * NOTE: this only fixes the issue for locks that do not have timeouts
* add a lock implementation using Lua scripts.Andy McCurdy2014-06-011-8/+94
|
* updated Lock class:Andy McCurdy2014-06-011-0/+158
* now uses unique string tokens to claim lock ownership * added extend() method to extend the timeout on an already acquired lock