Package memlock allows multiple appengine handlers to coordinate best-effort mutual execution via memcache. "best-effort" here means "best-effort"... memcache is not reliable. However, colliding on memcache is a lot cheaper than, for example, colliding with datastore transactions.
Deprecated: the implementation depends on the GAE Memcache API which is not available outside of the GAE first-gen runtime. There's currently no direct replacement, but one can be written on top of go.chromium.org/luci/server/redisconn if necessary.
ErrEmptyClientID is returned from TryWithLock when you specify an empty clientID.
ErrFailedToLock is returned from TryWithLock when it fails to obtain a lock prior to invoking the user-supplied function.
func TryWithLock ¶
TryWithLock attempts to obtains the lock once, and then invokes f if successful. The context provided to f will be canceled (e.g. ctx.Done() will be closed) if memlock detects that we've lost the lock.
TryWithLock function returns ErrFailedToLock if it fails to obtain the lock, otherwise returns the error that f returns.
`key` is the memcache key to use (i.e. the name of the lock). Clients locking the same data must use the same key. clientID is the unique identifier for this client (lock-holder). If it's empty then TryWithLock() will return ErrEmptyClientID.
Note that the lock provided by TryWithLock is a best-effort lock... some other form of locking or synchronization should be used inside of f (such as Datastore transactions) to ensure that f is, in fact, operating exclusively. The purpose of TryWithLock is to have a cheap filter to prevent unnecessary contention on heavier synchronization primitives like transactions.