Showing posts with label transaction. Show all posts
Showing posts with label transaction. Show all posts

Tuesday, 12 June 2012

Database Transaction

A Database Transaction can be understood as single unit of a logical operation in a database. It consists of one or more data operations performed together.

To understand the concept, let's take an example of a database of a bank. Here we have two accounts one for Mr. A and other for Mr. B represented by Table A and Table B in the database.

To transfer some amount of money from Mr. A's account to Mr. B's account as a payment, there are two logical steps:
  1. Deduct money from Mr A's account. i.e. Make an entry of money withdrawal in Table A.
  2. Deposit same amount of money to Mr. B's account. i.e. Make an entry of money depositin Table B.
There is no sense in doing either one of these steps alone. So, any of these steps alone doesn't qualify as a transaction.
It makes sense only when both of these steps are performed together. Hence constitute as a logical operation.  i.e. Transaction.

Here is a more detailed article on the topic on Wikipedia. You might be interested in this article as well.

Monday, 11 June 2012

Atomicity in Database

It's time to discuss the Atomicity of a database in little more detail. But before we begin, here is a disclaimer.

Disclaimer: this post has no relation whatsoever to this , this and this

Now, I mentioned in my previous post that the transaction on an atomic database follows "all or none" rule. So, here it means that a database transaction is either successful or failed.

There is no such thing as partial successful/failed transaction. If any part of transaction fails, the whole transaction fails. (See this to learn about a database transaction)

e.g. A there is database transaction consisting of three steps occurring serially (to move record from one table to other table).
  1. Copy a row from one table to a other table
  2. Delete the same from first table
  3. Commit the changes on database.
So, to be an Atomic database it should be programmed in such a way that if any of these step fail during the transaction, the whole transaction must fail and all the previous successful steps of the same failed transaction must be undone.

In above example, if step 2 fails, the step 3 should not occur and step 1 should be undone (rolled-back). This transaction will be successful only if all the steps are successful.

In the nutshell, in an atomic database, either all statements or steps in a database transaction are successful or none.

Here is the Wikipedia link on the same topic.