diff --git a/semester4/dmdb/data-modelling-databases-summary.pdf b/semester4/dmdb/data-modelling-databases-summary.pdf index 4b59d8b..36aad43 100644 Binary files a/semester4/dmdb/data-modelling-databases-summary.pdf and b/semester4/dmdb/data-modelling-databases-summary.pdf differ diff --git a/semester4/dmdb/glossary/basics.tex b/semester4/dmdb/glossary/basics.tex index da242b9..0dc5618 100644 --- a/semester4/dmdb/glossary/basics.tex +++ b/semester4/dmdb/glossary/basics.tex @@ -8,11 +8,11 @@ } \newglossaryentry{record}{ name={record}, - description={} + description={Typically a row or tuple in the database} } \newglossaryentry{schema}{ name={schema}, - description={A set of relations} + description={A set of relations, defining the attributes of the tuples} } \newglossaryentry{bag}{ name={bag}, diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/01_acid.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/01_acid.tex index 2cc7135..0efe8fd 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/01_acid.tex +++ b/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. diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex index e2cd6e2..394d411 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex +++ b/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$) diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex index 433dfc0..51a418b 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex +++ b/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: diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/04_two-phase-locking.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/04_two-phase-locking.tex index fb340ae..0fa69ab 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/04_two-phase-locking.tex +++ b/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} diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/05_snapshot-isolation.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/05_snapshot-isolation.tex index 5a9f84f..8226058 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/05_snapshot-isolation.tex +++ b/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. diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex index 339a3f6..c7472ae 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex +++ b/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} diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/07_recovery-procedures.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/07_recovery-procedures.tex index 3d8325e..87a7574 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/07_recovery-procedures.tex +++ b/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.