Add repo link

_chapters/07.md

@@ -12,19 +12,22 @@ Interesting items to be discussed:
 - concurrency control
 - race conditions
 - isolations (i.e *read committed, snapshot isolation and serializability.*)
+
 ## The slippery concept of a transaction
 
 > There emerged a popular belief that transactions were the antithesis of scalability, and that any large-scale system would have to abandon transactions in order to maintain good performance and high availability [5, 6].
 > VS
 > On the other hand, transactional guarantees are sometimes presented by database vendors as an essential requirement for “serious applications” with “valuable data”. 
 > 
 > **Both viewpoints are pure hyperbole.**
+
 ### The meaning of ACID
 
 > in practice, one database’s implementation of ACID does not equal another’s implementation
 > 	i.e. a lot of ambiguity around the meaning of **isolation**
 
 Half of ACID concepts are non-DB related
+
 #### ACID vs BASE
 
 Atomicity, Consistency, Isolation and Durability.
@@ -34,6 +37,7 @@ Basically Available, Soft state and Eventual consistency (Leaderless Replication
 
 The ability to abort a transaction on error, and have all writes from that transaction
 discarded, is the defining feature of ACID atomicity
+
 #### Consistency - not really a DB concept
 
 an application-specific notion of the database being in a “good state”.
@@ -42,25 +46,30 @@ an application-specific notion of the database being in a “good state”.
  this idea of consistency depends on the application’s notion of invariants,
 and it’s the application’s responsibility to define its transactions correctly so that they
 preserve consistency.
+
 #### Isolation - txns run serially
 
 Isolation in the sense of ACID means that concurrently executing transactions are
 isolated from each other: they cannot step on each others’ toes
 > read -> they had run serially
+
 #### Durability - not really a DB concept
 
 data it has written will not be forgotten, even if there is a hardware fault or the database crashes.
 > usually also involves a write-ahead log or similar (see “Update-in-place vs. append-only logging”
+
 ### Single-object and multi-object operations
 
 Based on above -> we will focus on `Atomicity` and `Isolation` then
+
 #### Single Object Writes
 
 - Atomicity can be implemented using a log for crash recov‐
 ery (see “Update-in-place vs. append-only logging” on page 80), 
 - isolation can be implemented using a lock on each object (allowing only one thread to access an object at any one time).
 
 Generally  useless, as a transaction is usually understood as a mechanism for grouping multiple operations on multiple objects into one unit of execution.
+
 #### Multi Object Writes
 
 ## Weak isolation levels

index.md

@@ -3,6 +3,7 @@
 # other options
 ---
 
+[Repo](https://github.com/friendlyantz/book-notes-designing-data-intensive-apps)
 * [Web version](https://friendlyantz.github.io/book-notes-designing-data-intensive-apps/)
 {:toc}