As the API for the marketplace was being completed, it was decided that there should
be a method for users to stream all item listings as they happen, along with a stream
for all purchases that actually occur. The semaphore method that we created only supports
a timeout of 10 seconds, primarily to deal with timeouts and possible bugs on
our side of things. But users of the streaming portion of the API will want to keep connected
for much longer than 10 seconds, so we need a method for refreshing the
semaphore so that it doesn’t time out.
Because we already separated the timeout ZSET from the owner ZSET, we can actually
refresh timeouts quickly by updating our time in the timeout ZSET, shown in the
As long as we haven’t already timed out, we’ll be able to refresh the semaphore. If we
were timed out in the past, we’ll go ahead and let the semaphore be lost and report to
the caller that it was lost. When using a semaphore that may be refreshed, we need to
be careful to refresh often enough to not lose the semaphore.
Now that we have the ability to acquire, release, and refresh a fair semaphore, it’s
time to deal with our final race condition.
TRY REDIS ENTERPRISE CLOUD FREE
Redis Enterprise Cloud provides complete automation of day-to-day database operations. Start now with 30MB of free storage.
© 2021 Redis Labs. Redis and the cube logo are registered trademarks of Redis Labs Ltd.