You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simplify PersistenceBarrier to two states: Inactive and Active
Remove the Armed state. No race is possible because the barrier is
activated on the same thread that just released the write lock, and
the PREPARE is sent to the durability worker directly (not through
send_or_buffer_durability) before the barrier activates.
Copy file name to clipboardExpand all lines: crates/core/2PC-IMPLEMENTATION-PLAN.md
+9-7Lines changed: 9 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -153,17 +153,19 @@ On replay, when encountering a PREPARE:
153
153
154
154
## Persistence barrier
155
155
156
-
The barrier in `relational_db.rs` has three states: `Inactive`, `Armed`,`Active`.
156
+
The barrier in `relational_db.rs` has two states: `Inactive` and`Active`.
157
157
158
158
-**Inactive**: normal operation, durability requests go through.
159
-
-**Armed**: set BEFORE committing the transaction (while write lock is held). The NEXT durability request (the PREPARE) goes through to the worker and transitions the barrier to Active.
160
-
-**Active**: all subsequent durability requests are buffered.
159
+
-**Active**: all durability requests are buffered.
161
160
162
-
This ensures no race between the write lock release and the barrier activation. Since the barrier is Armed while the write lock is held, no other transaction can commit and send a durability request before the barrier transitions to Active.
161
+
No race is possible because the barrier is activated on the same thread that holds the write lock. The sequence on both coordinator and participant is:
162
+
163
+
1. Commit in-memory (releases write lock)
164
+
2. Send PREPARE to durability worker (direct call, bypasses barrier)
165
+
3. Activate barrier
166
+
167
+
Steps 1-3 happen sequentially on one thread. No other transaction can commit between 1 and 3 because steps 2 and 3 are immediate (no async, no lock release between them). By the time another transaction acquires the write lock and commits, the barrier is already active and its durability request is buffered.
163
168
164
-
Used by both coordinator and participant:
165
-
- Arm before committing the 2PC transaction
166
-
- The commit's durability request (the PREPARE) transitions Armed -> Active
0 commit comments