| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During a call to `acquire()`, if the call is `blocking` and has a
`blocking_timeout` set, it uses `time.time()` calls to determine when to
give up attempting to acquire the lock.
However, since `time.time()` is marked as "adjustable", it is possible
for it to go backwards or forwards at a rate other than 1 second per
second, meaning the spinloop may exit earlier or later than expected.
By changing the implementation to use `time.monotonic()`, which is
guaranteed to never go backwards, and not be affected by system clock
updates, this potential problem is fixed.
For the same reason, some time dependent lock tests have also been
changed to use `time.monotonic()`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove support for end-of-life Python 2.7
Python 2.7 is end of life. It is no longer receiving bug fixes,
including for security issues. Python 2.7 went EOL on 2020-01-01. For
additional details on support Python versions, see:
Supported: https://devguide.python.org/#status-of-python-branches
EOL: https://devguide.python.org/devcycle/#end-of-life-branches
Removing support for EOL Pythons will reduce testing and maintenance
resources while allowing the library to move towards a modern Python 3
style. Python 2.7 users can continue to use the previous version of
redis-py.
Was able to simplify the code:
- Removed redis._compat module
- Removed __future__ imports
- Removed object from class definition (all classes are new style)
- Removed long (Python 3 unified numeric types)
- Removed deprecated __nonzero__ method
- Use simpler Python 3 super() syntax
- Use unified OSError exception
- Use yield from syntax
Co-authored-by: Andy McCurdy <andy@andymccurdy.com>
|
| |
|
| |
Covers the class redis.utils.dummy.
|
| |
|
|
|
|
|
| |
Lock.extend() now has a new option, `replace_ttl`. When False (the
default), Lock.extend() adds the `additional_time` to the lock's existing
TTL. When replace_ttl=True, the lock's existing TTL is replaced with
the value of `additional_time`.
|
| |
|
|
|
|
|
|
|
| |
When waiting to acquire a lock, the Lock object will sleep until
the lock is acquired or until blocking_timeout has elapsed. This optimization
calculates whether the next iteration will occur after blocking_timeout
has elapsed and short circuits it immediately.
Fixes #1263
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
| |
Lock.locked() returns a boolean indicating if the lock is acquired and valid.
Thanks Alan Justino da Silva
Fixes #1007
|
| |
|
|
|
| |
Fixes #621
Fixes #927
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
redis-py maintained backwards compatibility by keeping the old "Redis"
class around for quite some time. While no doubt a convenience for folks
who relied on it, the presence of both Redis and StrictRedis causes
a number of support issues and general confusion. With 3.0, we're
breaking a few things to make redis-py better going forward.
This change removes the old Redis class. We also renamed the StrictRedis
class to Redis and aliased StrictRedis to Redis. For people that have
been using StrictRedis, this should not change anything. You can continue
doing things as you are.
People still using the legacy Redis class will need to update the argument
order for the SETEX, LREM and ZADD commands. Additionally, the return values
for TTL and PTTL now return the integer values -1 when a key exists but
has no expire time and -2 when a key does not exist. Previously these
cases returned a None value in the Redis class.
|
| |
|
|
| |
All supported Python versions support the with statement.
|
| | |
|
| | |
|
| |
|
|
|
| |
* now uses unique string tokens to claim lock ownership
* added extend() method to extend the timeout on an already acquired lock
|
| | |
|
| |
|
