completed the draft of the first paper section

source/db2-presentation.tex

@@ -1,5 +1,8 @@
 \documentclass{beamer}
 \usepackage[utf8]{inputenc}
+\usepackage{graphicx}
+\usepackage{dirtytalk}
+\graphicspath{ {images/} }
 \usetheme{CambridgeUS}
 \usecolortheme{beaver}
 
@@ -56,9 +59,9 @@ Mixing this with a distributed scenario means the necessity to introduce complex
 \frametitle{The Starting Problem}
 Usually we pay coordination overhead in term of:
 \begin{itemize}
-  \item Increased latency \pause
-  \item Decreased throughput \pause
-  \item Unavailability (in case of failures)
+  \item Increased latency.
+  \item Decreased throughput.
+  \item Unavailability (in case of failures).
 \end{itemize}
 \end{frame}
 
@@ -69,29 +72,84 @@ The authors of the paper discuss this new technique (or better analysis framewor
 
 \begin{frame}
 \frametitle{Invariant Confluence}
-The main idea here is not to introduce some new exotic way to improve the coordination task, but instead the authors predicate on the fact that there is a set of workloads that do not require coordination, and that can be executed in parallel. The programmer at the application level can then state in an explicit way the \emph{invariants}, special attributes of the tables that need coordinate in the case of concurrent operations executing on them.
+The main idea here is not to introduce some new exotic way to improve the coordination task, but instead the authors predicate on the fact that there is a set of workloads that do not require coordination, and that can be executed in parallel. The programmer at the application level can then state in an explicit way the \emph{invariants}, special attributes of the tables that need coordination in case of concurrent operations executing on them.
 \end{frame}
 
 \begin{frame}
 \frametitle{The Model}
 The main concepts introduced:
 \begin{itemize}
-  \item Invariants
-  \item Transactions
-  \item Replicas
-  \item (\emph{I-})Convergence
+  \item Invariants \pause
+  \item Transactions \pause
+  \item Replicas \pause
+  \item (\emph{I-})Convergence \pause
   \item Merging
 \end{itemize}
 \end{frame}
 
 \begin{frame}
-\frametitle{Template}
-Template text
+\frametitle{Convergence}
+This is a figure that explains the main concept behind the idea of convergence:
+\includegraphics[width=\textwidth]{convergence}
 \end{frame}
 
 \begin{frame}
-\frametitle{Template}
-Template text
+\frametitle{Coordination-Free Execution}
+Here instead we show the basic evolution of a simple coordination free execution and the consequent merging operation:
+\includegraphics[width=\textwidth]{coordination-free}
+\end{frame}
+
+\begin{frame}
+\frametitle{Invariants}
+\begin{itemize}
+  \item It is important to note that \textbf{coordination can only be avoided if all local commit decisions are globally valid.}\pause
+  \item So the best approach to guarantee the application level consistency is to apply a convergence analysis and then identify the \emph{true conflicts}. The uncertain situations must be threated in a conservative approach. \pause
+  \item This means that we rely on the analysis done by the programmer at the application level to guarantee the correctness. This is clearly a drawback.
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Invariants}
+Luckily there are some standard situations for the analysis of invariants that we can use as boilerplate in the building of the set of invariants of our application, this figure summarizes the main cases:
+\centering
+\includegraphics[width=0.85\textwidth,height=0.7\textheight]{invariants}
+\end{frame}
+
+\begin{frame}
+\frametitle{Benchmarking}
+\begin{itemize}
+  \item The authors then proceeded to implement this new framework and test it with a standard benchmark, the TPC-C benchmark, that is said to be \say{the gold standard for database concurrency control both in research and industry.}
+  \item They also used RAMP transactions, that are transactions that \say{employ limited multi-versioning and metadata to ensure that readers and writers can always proceed concurrently.}
+  \item The selected language for the prototype is Scala, used for reason of compactness of the code.
+\end{itemize}
+\end{frame}
+
+\begin{frame}
+\frametitle{Results}
+In the next few slides there are some plots of the result obtained in the benchmarks by the authors. The New-Order label refers to the fact that the authors when an unique id assignment was needed, they assigned a \emph{temp-ID}, and only just before the commit a sequential \emph{real-ID} was assigned, and a table mapping \emph{tmp-ID} to \emph{real-ID} created.
+\end{frame}
+
+\begin{frame}
+\frametitle{Results}
+\begin{figure}
+\caption{TPC-C New-Order throughput across eight servers.}
+\centering
+\includegraphics[width=0.55\textwidth,height=0.73\textheight]{results1-1}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Results}
+\begin{figure}
+\caption{Coordination-avoiding New-Order scalability.}
+\centering
+\includegraphics[width=0.70\textwidth,height=0.70\textheight]{results1-2}
+\end{figure}
+\end{frame}
+
+\begin{frame}
+\frametitle{Conclusions}
+This paper demonstrates that ACID transactions and associated strong isolation levels dominated the field of database concurrency. This is a powerful abstractions that automatically guarantee consistency at the application level. In a distributed scenario where we want to achieve \textbf{high scalability}, we can sacrifice these abstractions and perform an \textbf{I-Confluence} analysis in order to exploit scalability through \textbf{coordination-free} transactions
 \end{frame}