From 9b14d4215bc6a649da1456bc590f179159858067 Mon Sep 17 00:00:00 2001
From: Sameer Rahmani
Date: Sat, 27 Apr 2019 00:48:04 +0100
Subject: [PATCH] transactions draft has been added
---
_drafts/variant-types-of-transactions.md | 116 +++++++++++++++++++++++
_layouts/home.html | 5 +-
_layouts/post.html | 2 +-
_sass/code.scss | 4 +
assets/styles/web.sass | 22 +++--
coh.md | 9 +-
6 files changed, 142 insertions(+), 16 deletions(-)
create mode 100644 _drafts/variant-types-of-transactions.md
diff --git a/_drafts/variant-types-of-transactions.md b/_drafts/variant-types-of-transactions.md
new file mode 100644
index 0000000..d1524eb
--- /dev/null
+++ b/_drafts/variant-types-of-transactions.md
@@ -0,0 +1,116 @@
+---
+layout: post
+title: "Variant of database transactions"
+date: 2019-04-26
+categories: DB
+tags: transaction
+theme: dark
+---
+
+In this post I want to talk about different variants of
+[database transactions](https://en.wikipedia.org/wiki/Database_transaction), I assume you already
+know about database transactions. So, let's cut to the chase.
+
+## Flat Transaction
+Flat transaction are those regular transactions we know about and are the most common transactions
+in the [DBMS](https://en.wikipedia.org/wiki/Database#Database_management_system)s.
+
+Flat transactions are simple but they can not address two problems:
+
+* Multi stage transactions
+For example, Let's say we want to book flight from City C1 to C2. Since there is no direct fly we
+have to book 4 flights from, `C1 -> CA -> CB -> C2`. The process of booking each of these flights
+is a transaction by itself and the whole process is a transaction too.
+
+* Bulk updates
+Let's say we want to update billion tuples. What if the very last tuple fails to update. Then we
+need to revert our changes to a billion tuples.
+
+## Savepoints transactions
+These transactions are similar to save point transaction but they have one extra thing which is
+save points So any where in there transaction users case ask for a save point and again they can
+rollback to a save point or rollback the entire transaction.
+
+```sql
+BEGIN
+ READ(A)
+ WRITE(A)
+ SAVEPOINT 1
+ WRITE(B)
+ SAVEPOINT 2
+ ROLLBACK 2
+COMMIT
+```
+
+Note: **These transactions only solve the multi stage transaction problem.**
+
+## Nested transactions
+Nested transactions are similar to save points transactions, but instead save points these
+transactions break down to smaller flat transactions. Each transaction commits separately from
+other transactions. But result of the parent transaction rule them all, so if the parent
+transaction fails all the nested transactions have to rollback.
+
+```sql
+ BEGIN
+ BEGIN T1
+ ...
+ COMMIT T1
+ BEGIN T2
+ ...
+ COMMIT T2
+ COMMIT
+```
+
+Note: **These transactions only solve the multi stage transaction problem.**
+
+## Chained transactions
+In these kind of transactions, smaller flat transaction can be applied in a chain in the way that
+the result of each of them is not visible to the outside world until the end of the chain.
+
+In theory chained transactions should be applied in sequence but in practice in some cases we can
+interleave their operations. Also Between T1 and T2 of a chained transaction, No other thread of
+code shouldn't be able to make changes to those resources which T2 will operates on.
+
+If any transaction in the chain fails, it has nothing to do with the previous transactions in the
+chain. For example:
+
+```
+ T1 -> T2 -> T3
+ S -> S -> F
+```
+
+In the chained transaction above only T3 failed and T1 and T2 are successfully committed to storage.
+We don't have to roll them back.
+
+While chained transactions can break big transactions into smaller pieces for better parallelism but
+**they only solve the multi stage transaction problem** Not the bulk update problem.
+
+## Compensating transactions
+This type of transactions are special transactions which are designed to semantically reverse the
+effect of another transaction which already committed.
+
+One important thing to remember about compensating transactions is that they know how to revert
+the *logical* effect of other transactions *NOT the physical* effect. For example, If a transaction
+increase a counter by one. The physical revert would be to changes the binary data that inserted
+for that counter to what it was before the transaction, but the logical revert would be to
+decrease the counter by one when needed.
+
+So basically these kind of transactions know about how to put the database in correct state before
+the other transaction.
+
+## Saga Transactions
+A saga transaction is a sequence of chained transactions `T1 - Tn` and compensating transaction
+`C1 - C(n-1)` where the following guaranteed:
+
+* The transactions will commit in the order `T1...Tj`, `Cj...C1` (where `j < n`).
+
+So basically this means that a saga transaction is a seq of chained transactions which applies the
+smaller transactions in order with their corresponding compensating transactions.
+
+In a chained transaction when ever transaction Tn aborts, the transactions before Tn stay committed,
+but in saga transactions they will be rollback using compensating transactions that know how to
+roll them back *logically*.
+
+So Saga transactions can be fix both multi-staging and bulk update problems. But the issue here is
+that the compensating transactions are something that requires application level understanding of
+the use case so most of the time they are implemented in the application frameworks instead of DBMSs.
diff --git a/_layouts/home.html b/_layouts/home.html
index d80fb3b..8df7fe3 100644
--- a/_layouts/home.html
+++ b/_layouts/home.html
@@ -12,8 +12,9 @@ layout: default
/>
- Hi! I'm Sameer and I usally write about technology and software
- development (hmmm more like nagging instead of writing).
+ Hi! I'm Sameer and I usally write about
+ technology and software development (hmmm more like nagging instead of writing). Since
+ I'm lazy, my posts are short so I can write more often.
diff --git a/_layouts/post.html b/_layouts/post.html
index aac2144..42499c9 100644
--- a/_layouts/post.html
+++ b/_layouts/post.html
@@ -4,7 +4,7 @@ theme: dark
---
-
+
{{page.title}}
diff --git a/_sass/code.scss b/_sass/code.scss
index d5bc47e..c5279c4 100644
--- a/_sass/code.scss
+++ b/_sass/code.scss
@@ -59,3 +59,7 @@
.highlight .vg { color: #003333 } /* Name.Variable.Global */
.highlight .vi { color: #003333 } /* Name.Variable.Instance */
.highlight .il { color: #FF6600 } /* Literal.Number.Integer.Long */
+
+pre.highlight {
+ padding: 4px 8px;
+}
diff --git a/assets/styles/web.sass b/assets/styles/web.sass
index de157ce..6ef72a3 100644
--- a/assets/styles/web.sass
+++ b/assets/styles/web.sass
@@ -12,7 +12,8 @@
$white-ter: #fafafa
$footer-background-color: $white-ter
-$purple: #433983
+$purple: #49438B //#4A448C //#433983
+$blue: #82C2E5
$family-primary: 'Lato'
$family-secendary: 'Lato Bold'
$background: $white-ter
@@ -62,6 +63,7 @@ body.dark
background: $purple
with: 100%
height: 100%
+
a
color: $white
@@ -73,20 +75,23 @@ body.dark
text-align: justify
h1
- @extend .is-size-1
- h2
@extend .is-size-2
- h3
+ h2
@extend .is-size-3
- h4
+ h3
@extend .is-size-4
- h5
+ h4
@extend .is-size-5
+ h5
+ @extend .is-size-6
- p, h1, h2, h3, h4, h5
+ p, h1, h2, h3, h4, h5, strong
padding-top: 1em
padding-bottom: 0.5em
line-height: 1.5
+ color: darken($white, 10%)
+ strong
+ color: white
p
text-align: justify
@@ -95,8 +100,7 @@ body.dark
li
margin-left: 1em
a
- color: lighten($purple, 40%)
- font-weight: 700
+ color: $blue
&:hover
text-decoration: underline
diff --git a/coh.md b/coh.md
index 307c8e1..53985cc 100644
--- a/coh.md
+++ b/coh.md
@@ -9,18 +9,19 @@ I always try live by my code of honor. A man is nothing without his honor. A sin
## Honorable life
* Don't betray your code of honor.
-* Defend your bushido way.
+* Defend your Bushido way.
* Live life as a Honorable Man.
* Don't talk without a knowledge to support it.
-* "Don't argue with the crazy the crazy guy".
+* "Don't argue with the crazy guy".
* Always follow your sense of Justice
* Feel the pain of others.
* Always put your self in people's shoe before making any decision.
* A simple smile goes a long way.
* There's no honor in winning by cheating.
-* "If you falldown 7 times make sure to get up 8 times."
+* "If you fall down 7 times make sure to get up 8 times."
* Protect your promises.
* "For a samurai everywhere is Japan."
+* Holding back is disrespectful to your opponent
## Programming
* Simplicity over Complexity
@@ -35,7 +36,7 @@ I always try live by my code of honor. A man is nothing without his honor. A sin
### New Feature Checklist
* Is it easy to extend the feature ?
* Is it scalable ?
-* Is it easy to maintan ?
+* Is it easy to maintain ?
* Is it well documented ?
* Does it have the best possible performance ?
* What about tests ?