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 ?