1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
//! Distributed lock backend trait for beat scheduler
//!
//! Provides the `DistributedLockBackend` trait that enables distributed lock
//! management across multiple beat scheduler instances. Implementations can
//! use Redis, databases, or in-memory stores as the backing mechanism.
use async_trait;
/// Backend for distributed lock management.
///
/// Used by the beat scheduler to prevent duplicate task execution across
/// multiple scheduler instances. Each implementation provides atomic
/// lock operations with TTL-based expiration.
///
/// # Lock Semantics
///
/// - Locks are identified by a string key (typically the task name)
/// - Each lock has an owner (typically the scheduler instance ID)
/// - Locks expire after a configurable TTL to prevent deadlocks
/// - Only the owner can release or renew a lock
///
/// # Example
///
/// ```ignore
/// use celers_core::lock::DistributedLockBackend;
///
/// async fn schedule_task(backend: &dyn DistributedLockBackend) {
/// let acquired = backend.try_acquire("my_task", "scheduler-1", 300).await.unwrap();
/// if acquired {
/// // Execute the task
/// // ...
/// backend.release("my_task", "scheduler-1").await.unwrap();
/// }
/// }
/// ```