Locks
Lock options
Tune TTL, owner, wait bounds, and namespace via LockOptions and its builder.
Both Mutex and RwLock are configured with LockOptions. The required pieces are the key and the connection; everything else has a sensible default.
Fields
pub struct LockOptions {
pub key: DistkitRedisKey, // the resource being locked
pub connection_manager: ConnectionManager,
pub namespace: DistkitRedisKey, // key prefix (default "distkit-locks")
pub ttl: Duration, // lease length (default 30 s)
pub owner_id: Option<String>, // default: a fresh UUID v4
pub max_wait: Option<Duration>, // cap on waiting acquires (None = wait forever)
pub retry_interval: Duration, // poll gap while waiting (default 50 ms)
}
A few notes:
ttlis the lease length. The lock renews itself everyttl/3, so the ttl only matters if the holder dies - then the lock frees after at mostttl. Shorter ttl means faster recovery from a dead holder but more renewal traffic.owner_ididentifies the holder. Leave itNoneto get a UUID. Set it explicitly only if you need a holder to reattach to a lock it already owns.max_waitbounds the waitinglock/read/writecalls. WithNone, they wait indefinitely.namespaceprefixes the Redis keys distkit creates, keeping lock keys separate from your other data.
The simple constructor
use distkit::{DistkitRedisKey, lock::LockOptions};
let key = DistkitRedisKey::try_from("my_resource".to_string())?;
let options = LockOptions::new(key, conn); // all defaults
The builder
For anything beyond defaults, use the builder:
use std::time::Duration;
use distkit::{DistkitRedisKey, lock::LockOptions};
let key = DistkitRedisKey::try_from("my_resource".to_string())?;
let options = LockOptions::builder(key, conn)
.ttl(Duration::from_secs(10))
.retry_interval(Duration::from_millis(20))
.max_wait(Duration::from_secs(5))
.owner_id("worker-7")
.build();
The builder methods mirror the fields: namespace, ttl, owner_id, max_wait, retry_interval, then build().

