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 ---