mirror of
https://github.com/janishutz/eth-summaries.git
synced 2026-07-27 21:29:09 +02:00
47 lines
3.0 KiB
TeX
47 lines
3.0 KiB
TeX
\subsection{ACID}
|
|
\label{sec:acid}
|
|
\acrshort{acid} is the conventional notion of correctness (informal because it's an acronym):
|
|
\begin{itemize}
|
|
\item \bi{Atomicity}: A group of operations must take place in their entirety or not at all
|
|
\item \bi{Consistency}: Operations should take the database from a correct state to another correct state
|
|
\item \bi{Isolation}: Concurrent execution of operations should yield predictable and correct results
|
|
\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.
|
|
|
|
\inlinedefinition[Correct application] The model of correct executions of operations is sequential executions.
|
|
|
|
\inlinedefinition[Operations] The operations for transactions are inserts, updates and deletion of tuples.
|
|
|
|
\inlinedefinition[Consistency] The assumption of correctness of transactions is based on two things:
|
|
\bi{(1)} the user doesn't apply wrong transactions and \bi{(2)} the DBMS has mechanisms to prevent incorrect modifications, such as violations of constraints, etc.
|
|
|
|
\inlinedefinition[Durability] ensures that the changes of a completed transaction are remembered by the system and can be recovered.
|
|
This is often more strict and DBMS will keep the DB st ate and a history of all transactions.
|
|
|
|
The transaction history is captured in the DB log. The state at a given moment is captured in snapshots.
|
|
The log and snapshots allow to go back and forward in the history of the database by undoing or redoing transactions from a given snapshot.
|
|
Thus, very similar in concept to what \texttt{git} uses.
|
|
|
|
|
|
\subsubsection{Atomicity}
|
|
\inlinedefinition[Atomicity] dictates that a transaction only takes effect if it can be executed in its entirety, or in other words,
|
|
a transaction has to be executed in its entirety or not at all.
|
|
The issue with this is that violations are costly to correct.
|
|
|
|
Thus, atomicity requires isolation. If a transaction can see the intermediate state created by another transaction, then its input is not guaranteed to be consistent,
|
|
implying that its output is not guaranteed to be consistent, either.
|
|
|
|
The DBMS get around this issue by isolating the transactions, such that they behave as if they were alone in the database.
|
|
This of course means that we need to know when a transaction is completed so we can \textit{commit} it, if there are no conflicts.
|
|
If there are conflicts, we have to resolve them, rerun the transaction (note that this can be very expensive) or to prevent them altogether.
|
|
|
|
The isolation is enforced through concurrency control mechanisms to prevent conflicts.
|
|
The canonical concurrency control mechanism in DBs is locking.
|
|
We use locking policies to ensure that the transactions are isolated.
|