From beb379d99877f5fef3c7841f1e6b37fdcb095665 Mon Sep 17 00:00:00 2001
From: Oliver <okennedy@buffalo.edu>
Date: Wed, 4 Sep 2019 23:46:54 -0400
Subject: [PATCH] FDB Notes and Lazy Transaction Notes

---
 .../2019fa/slide/2019-09-03-FunctionalDS.erb  | 10 +++
 .../slide/2019-09-05-LazyTransactions.erb     | 68 +++++++++++++++++++
 2 files changed, 78 insertions(+)
 create mode 100644 src/teaching/cse-662/2019fa/slide/2019-09-05-LazyTransactions.erb

diff --git a/src/teaching/cse-662/2019fa/slide/2019-09-03-FunctionalDS.erb b/src/teaching/cse-662/2019fa/slide/2019-09-03-FunctionalDS.erb
index 9cb5c238..a924170b 100644
--- a/src/teaching/cse-662/2019fa/slide/2019-09-03-FunctionalDS.erb
+++ b/src/teaching/cse-662/2019fa/slide/2019-09-03-FunctionalDS.erb
@@ -4,6 +4,16 @@ title: Functional Data Structures
 date: Sept. 3
 ---
 
+<!-- 2019 by OK
+    Most of the deck works, but some of the do-it-yourself examples need work.
+    - The set example didn't happen... can probably cut that.
+    - Example 3 needs more lead-up.  In particular, it would be good to emphasize how lazy evaluation works (i.e., lazy references).
+    - It might be helpful to rephrase example 3 in terms of REPLACE rather than APPEND.
+    - It might be helpful to have a summary takeaway --- Lazy evaluation allows limited mutability, BUT in a very controlled, and **monotone** way.
+    
+    Parts of the amortized analysis fell a bit flat.  It might be useful to start off with a bit more of a motivating example.  In particular, a timeline of 'time' for each operation might be helpful, as well as an emphasis on computing "Average" rather than "Worst-case" behavior.
+  -->
+
 <section>
   <section>
     <p><span class="fragment highlight-red">Mutable</span> vs Immutable Data</p>
diff --git a/src/teaching/cse-662/2019fa/slide/2019-09-05-LazyTransactions.erb b/src/teaching/cse-662/2019fa/slide/2019-09-05-LazyTransactions.erb
new file mode 100644
index 00000000..6b39addc
--- /dev/null
+++ b/src/teaching/cse-662/2019fa/slide/2019-09-05-LazyTransactions.erb
@@ -0,0 +1,68 @@
+---
+xtemplate: templates/cse662_2019_slides.erb
+title: Lazy Transactions
+date: Sept. 5
+---
+
+
+Questions
+- Why are timestamps needed?
+- How does the system figure out the read/write sets?
+- The Now phase is also required to determine the write set of the transaction: Which values get written to may be determined by the current state of the database.
+- Strengths/Weaknesses of lazy transactions on bursty workloads.  Where do/do not they work.
+- How to create spatial locality in transactions scheduled adjacently
+- Read latency: Really really bursty read costs.  How to avoid?
+- Normal distribution microbenchmark: Creating synthetic spatial locality as well.
+
+- Overview
+  - Transactions
+    - Declarative vs pl/X
+    - Read/Write Sets + Code
+    - Object here = record
+  - Challenges
+    - Parallel Execution
+    - Recap: 
+      - OCC
+      - Locking
+  - Guarantees required by Commit
+    - Xact guaranteed not to abort
+      - Deadlock / OCC conflict
+      - Constraint violation (Uniqueness, Domain, FK, etc...)
+        - Model as code that reads a set of values and returns Y/N
+    - Xact's effects are guaranteed to be visible to subsequent xacts
+- Simple Model: Sequential Execution
+  - How to improve: 
+    - Split commit check vs actual execution (Now vs Later)
+    - Collapse commit checks, excute in background
+      - Except what if we need to read a value?
+      - Naive: Force log execution up to the point
+- Graph model: Dependencies
+  - Total order vs Partial order
+  - Implementing
+    - List of Unexecuted Transactions
+      - Stored w/ Read Set + Write Set
+        - [[[ How do you get the Read/Write sets out? ]]]
+          - Might need to generate the read/write sets during the now phase.
+    - Key/value map / Versioned [[[ why? ]]]
+      - Value can be a reference to a transaction
+      - Like lazy excution: lazy value overwritten after transaction executes.
+    - Forcing a read (e.g., during the now phase) forces execution of everything before
+      - [[[ Why is this a problem? ]]]
+        - Burstiness!  Some reads might take absurdly long
+          - [[[ How do we fix this? ]]]
+            - Trade-off: Limit length of read chains
+              - [[[ How do we do this cheaply? ]]]
+                - Don't trace the graph depth (O(N) in the maximum graph depth)
+                - Keep a "depth" counter with each written value. 
+- [[[ How do you allocate worker threads ]]]
+  - Single-threaded sticky: Already working with lots of contentious data, with lots of very fast operations
+  - Multi-threaded workers: Natural parallelism exposed through read/write sets
+- Minimizing work during "Now" phase
+  - Optimize Uniqueness Checks by only consulting index (not actual record) --- does the key exist in the map?
+- Minimizing overhead
+  - Move fast, high-contention operations to the now phase
+  - Spatial locality
+- [[[ The authors claim that the system can absorb bursty workloads. When is this true / not true? ]]]
+- Graph review:
+  - Microbenchmark: Normal distribution creates spatial locality
+  - External Read Latency CDF : 10s reads vs 1ms!!!
\ No newline at end of file