auto

notes/salt.md

@@ -10,6 +10,9 @@ transactions are ill-equipped .....(performance vs programmability)"
 - key issue is to provide isolation at a finer granularity, same atomicity
   - nested transactions give subtrans' atomicity, isolate entire thing
 
+
+ *Allow isolation to be specified at smaller granularity than atomicity*
+
 ## Background
 
 ANSI iso levels:
@@ -33,7 +36,8 @@ Issues:
   - **alkaline** subtransactions
     - no other transactions can see state of *uncommitted alkaline subtrans*
     - **committed** alk subtrans state viewable by other BASE or alkaline transactions
-    - *not visible* (to ACID?) until entire BASE commit.
+    - *not visible* to ACID until entire BASE commit.
+	- intended for *partition-local* ops
   - **salt isolation** allows control of internal states visibility (among other BASE transactions)
   - each alkaline sub has associated *exception*
   - *BASE transactions look like ACID transactions to other ACID transactions*
@@ -42,26 +46,20 @@ Issues:
     - i.e. all operations successfully executed *or bypassed because of some exception*
   - aborted only if they encounter an error before the transaction is accepted (unlike ACID)
 
-## Isolation
+## Salt Isolation
 
 *"If two operations in different transactions conflict, then the temporal dependency
     that exists between the earlier and the later of these operations  must extend to the
     entire transaction"* (allows SALT to work w/ different isolation levels)
 
 *Isolation:* Let Q be the set of operation types {*read*, *range-read*, *write*} and let L and S
-be subsets of Q . Further, let $o_1$ in $txn_1$ and $o_2$ in $txn_2$, be two operations, respectively
-of type $T_1$ ∈ L and $T_2$ ∈ S , that access the same object in a conflicting
-(i.e. non read-read) manner. **If $o_1$ completes before $o_2$ starts, then $txn_1$ must decide
-before $o_2$ starts.**
-
-Isolation property holds if at least one is ACID, or both are alkaline.
+be subsets of Q . Further, let *o<sub>1</sub>* in *txn<sub>1</sub>* and *o<sub>2</sub>* in *txn<sub>2</sub>*, be two operations, respectively
+of type *T<sub>1</sub>* ∈ L and *T<sub>2</sub>* ∈ S , that access the same object in a conflicting
+(i.e. non read-read) manner. **If *o<sub>1</sub>* completes before *o<sub>2</sub>* starts, then *txn<sub>1</sub>* must decide
+before *o<sub>2</sub>* starts.**
 
+<img src=saltSets.png width=500>
 
-![sets](saltSets.png)
-
-
-## Salt Isolation
-**Salt Isolation**: 
 The Isolation property holds as long as (a) at least one of txn<sub>1</sub> and
 txn<sub>2</sub> is an ACID transaction or (b) both txn<sub>1</sub> and txn<sub>2</sub> are alkaline
 subtransactions.  
@@ -79,7 +77,7 @@ So:
       - alkaline - conflict w/ ACID and other alkaline
       - saline: conflict with ACID locks (except for read/read) only
     - lock duration
-      - *long term* (life of trans, 2PL) 
+      - *long term* (life of (sub-)trans, 2PL) 
       - *short-term* (just the op)
     - acquire only an alkaline lock at operation start
       - “downgrade” it to saline at end of subtransaction, hold until after the end of the BASE transaction. 
@@ -94,9 +92,9 @@ So:
 <p>
 Fixed by:
 
-- **Read-after-write across transactions** A BASE transaction B<sub>r</sub> that reads a value x, which has been written by another BASE<sub>w</sub> transaction, cannot release its saline lock on x until B<sub>w</sub> has released its own saline lock on x. 
+- **Read-after-write across transactions** A BASE transaction *B<sub>r</sub>* that reads a value x, which has been written by another *BASE<sub>w</sub>* transaction, cannot release its saline lock on x until *B<sub>w</sub>* has released its own saline lock on x. 
 
-- **Write-after-read within a transaction** An operation O<sub>w</sub> that writes a value x cannot
+- **Write-after-read within a transaction** An operation *O<sub>w</sub>* that writes a value x cannot
   release its saline lock on x until all previous read operations within the **same** BASE
   transaction have released their saline locks on their respective objects.