[DMDB] Notes on concurrency control

semester4/dmdb/parts/05_concurrency-control-recovery/01_acid.tex

@@ -8,6 +8,8 @@
     \item \bi{Durability}: The DB needs to remember the state it is in at all moments, even when failures occur
 \end{itemize}
 
+% TODO: Conflict Serializable histories
+
 \inlinedefinition[Database state] is the actual values stored in a database at a given point in time (in memory and storage).
 
 \inlinedefinition[Consistent state] is a database state that is the result of \textit{correctly} applying \textit{operations} to the DB.

semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex

@@ -1,3 +1,4 @@
+\newpage
 \subsection{Transaction Model}
 \inlinedefinition Some terms for Transaction model:
 \begin{itemize}
@@ -30,6 +31,7 @@ Below a list of very important syntax for the exam (where the subscript $i$ deno
 Conflicting operations are two operations on the same item with at least one of them being a write operation, such as $r_1[x] w_2[x]$ or $w_1[y] w_2[y]$.
 
 \subsubsection{History}
+\label{sec:tm-history}
 A history $H$ is a partially ordered $<_H$ sequence of operations from a set of transactions.
 If two operations are ordered within a transaction, they are equally ordered in the history.
 If two operations $p$ and $q$ conflict, then they are ordered with respect to each other ($p <_H q$ or $q <_H p$)

semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex

@@ -1,5 +1,5 @@
 \newpage
-\subsection{Concurrency Control}
+\subsection{Concurrency Control (CC)}
 The goal of concurrency control is to ensure the correct executions of concurrent transactions.
 The baseline for correctness is, as previously mentioned, serial execution.
 
@@ -14,7 +14,9 @@ and leaves the DB in a consistent state.
     \item Conflicting operations of non-aborted transactions are ordered in the same way in both histories
 \end{enumerate}
 
-\inlinedefinition[Serializable History] A history is serializable if and only it is equivalent to a serial history.
+\inlinedefinition[(Conflict) Serializable History] A history is serializable if and only it is equivalent to a serial history.
+
+A very simple way to check this is that a history is not CS if there are conflicting operations.
 
 \inlinetheorem[Serializability] A history is serializable if and only if its serializability graph is acyclic.
 The seerializabililty graph is constructed from the history graph as follows:

semester4/dmdb/parts/05_concurrency-control-recovery/04_two-phase-locking.tex

@@ -1,3 +1,4 @@
+\newpage
 \subsection{2 Phase Locking (2PL)}
 This type of locking is widely used since many decades and is the canonical implementation of concurrency control.
 Of course, alternatives exist and the locking implementation has a huge impact on performance and scalability.
@@ -7,11 +8,15 @@ The locks cover tuples, tables, indexes, blocks and more.
 
 Locks have different semantics that indicate whether they can be shared or are exclusive.
 
-Compatibility matrix:
+Compatibility matrix (S is shared lock, X is exclusive (for writing), NL is no lock, left for current, top for next state):
 \begin{tables}{cccc}{ & NL         & S          & X}
               S       & \checkmark & \checkmark & -  \\
               X       & \checkmark & -          & -  \\
 \end{tables}
+Note that to acquire any sort of exclusive lock (even if it's just an \textit{intention} to do so later on in the transaction),
+no lock can be held on that object and no other kind of lock can be acquired. For shared locks, as the name would imply,
+any number of threads can also acquire a shared lock on the object.
+
 
 \subsubsection{The protocol}
 \begin{enumerate}

semester4/dmdb/parts/05_concurrency-control-recovery/05_snapshot-isolation.tex

@@ -1,3 +1,4 @@
+\newpage
 \subsection{Snapshot isolation}
 This was initially used by Oracle and is a form of Multi-Version Concurrency Control (MVCC).
 
@@ -15,3 +16,7 @@ $T_2 \rightarrow T_1 \rightarrow T_2$.
 Depending on the application, this can still be correct (if this is for a ticketing system), but can also be disastrous (for e.g. a bank).
 
 If done properly however, it has significant performance advantages, as well as in distributed settings with replication.
+
+Note that a transaction cannot commit when a previous transaction has modified an object that this transaction has also modified,
+regardless of whether or not this transaction has read the object or not.
+Thus, the commit checks only check for writes, not for reads.

semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex

@@ -30,13 +30,16 @@ Databases typically log transactions by keeping before and after images of their
 
 
 \subsubsection{Recovery on histories}
+\begin{examdetails}
+    They like to ask about these, so be sure to understand this properly. Same goes for Conflict Serializability for histories (see \ref{sec:tm-history})
+\end{examdetails}
 A transaction $T_1$ reads from another transaction $T_2$ if $T_1$ reads a value written by $T_2$ at a time when $T_2$ was not aborted.
 
 We have:
 \begin{itemize}
-    \item \bi{Recoverable} (RC) history: If $T_i$ reads from $T_j$ and commits, then $c_j < c_i$
+    \item \bi{Recoverable} (RC) history: If $T_i$ reads from $T_j$ and commits, then $c_j < c_i$ (same goes for aborts)
     \item \bi{Avoids Cascading Aborts} (ACA) history: If $T_i$ reads $x$ from $T_j$, then $c_j < r_i[x]$
-    \item \bi{Strict} (ST) history: If $T_i$ reads from, or overwrites, a value written by $T_j$ then $c_j < r_i[x] / w_i[x]$ or $a_j < r_i[x] / w_i[x]$
+    \item \bi{Strict} (ST) history: If $T_i$ reads from, or overwrites, a value written by $T_j$ then $c_j < o_i[x]$ or $a_j < o_i[x]$, with $o = r$ or $o = w$ ($o$ is an operation)
 \end{itemize}
 
 

semester4/dmdb/parts/05_concurrency-control-recovery/07_recovery-procedures.tex

@@ -1,3 +1,4 @@
+\newpage
 \subsection{Recovery Procedures}
 \inlinedefinition[Recovery Manager] A recovery manager implements the recovery procedure, which depends on how the system functions.
 It may or may not require both, one or none of UNDO and REDO.