From b07109b4ac9351a16db9942fa7686a31ce013d3d Mon Sep 17 00:00:00 2001
From: "Peter J. Keleher" <keleher@cs.umd.edu>
Date: Tue, 31 Oct 2023 11:19:44 -0400
Subject: [PATCH] auto
---
notes/ram.md | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/notes/ram.md b/notes/ram.md
index 4919bfd..5eb5b80 100644
--- a/notes/ram.md
+++ b/notes/ram.md
@@ -227,20 +227,20 @@ When received by server:
- `prepare` (version/lock checks)
- `decision` (this phase in background, client already notified)
("the transaction is effectively committed once a durable lock record has been written for each of the objects")
+ - **strict serializability** using **optimistic cc**
- updates deferred until commit request
- reads executed normally, *versions recorded*
- writes on commit phase, possibly w/ expected version
+ - commit is two-phase
- fail *if version-check fails, or locked by another transaction*
+ - **decision** RPCs in background
- fast case
- *single server* owns all objects in transaction
- *read-only*, even in distributed case only a single round
- on client crash, recovery coordinator finishes, hoping to abort unless already committed
## Issues
-- worried that storing completion records will not scale well
- - local operation
- - either disk or (for RAMCloud) replicating elsewhere
-- why optional version checking in transactions? (atomic operation primitive)
+- background decision RPCs imply longer lock holding
## Questions/comments
--
GitLab