transactions draft has been added
This commit is contained in:
parent
8bc51c4208
commit
9b14d4215b
|
|
@ -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.
|
||||
|
|
@ -12,8 +12,9 @@ layout: default
|
|||
/>
|
||||
</p>
|
||||
<p class="info text-justified">
|
||||
Hi! I'm <b>Sameer</b> and I usally write about technology and software
|
||||
development (hmmm more like nagging instead of writing).
|
||||
Hi! I'm <b>Sameer</b> 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.
|
||||
</p>
|
||||
</section>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ theme: dark
|
|||
---
|
||||
|
||||
<div class="column is-half-desktop is-offset-one-quarter-desktop">
|
||||
<h1 class="is-size-1">
|
||||
<h1 class="is-size-2">
|
||||
{{page.title}}
|
||||
</h1>
|
||||
<div class="columns">
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
9
coh.md
9
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 ?
|
||||
|
|
|
|||
Loading…
Reference in New Issue