Skip to main content

DB transaction ACID properties

DB transaction is a combination of different operations. If not performed in a proper manner, different transactions working on the same data at the same time may leave the data in corrupted state, effecting the application. In this article, I am going to illustrate DB transaction ACID properties through an example of money transfer application between two different accounts A and B. To begin with, lets suppose that accounts A and B both have initial balance of $100.

ACID stands for Atomicity, Consistency, Isolation and Durability. Let's try to understand these one by one.
  • Atomicity: This is the property that mandates that if a transaction is started, either all the operations which are part of the transaction need to be completed by end of the transaction completion as a single unit of work or none of the operations needs to be completed. It is maintained by transaction management component. If a debit of $10 is made from account A, then the corresponding credit of $10 also needs to be made to account B.
  • Consistency: This property ensures that the data effected by the transaction remains in consistent state before the transaction starts and after that ends. It implies that all the keys, checks, data types and triggers are successful and no constraint violation have happened. It is the responsibility of the application developer to ensure consistency. If a debit of $10 is made from account A to account B, at the end of the transaction the total amount of money in A and B is (100-10+100+10=)200 which is same as the total amount of money before the transaction (100+100=)200.
  • Isolation: The whole idea behind this property is to ensure that two transaction operating on the same data are unaware of each other. No two transaction can update the same data at the same time. As a result the intermediate changes (uncommitted changes) done by one transaction aren't visible to other transaction. So, it appears to both of the transactions that they are operating in a sequential manner. If one transaction needs the data changes done by the other transaction, then it needs to wait until the other transaction completes. It is managed by the concurrency control manager. If one transaction makes of transfer of $10 from account A to account B, until the transaction is complete, another transaction running at the same time still sees each of the accounts A and B has balance of $100.
  • Durability: This property ensures the data changes are permanent after successful completion of transaction. The data needs to be stored on a disk so that in case of a system failure, the changes aren't undone and still remain safe. It is the responsibility of the recovery manager to ensure the property is enforced. If a debit of $10 is made from account A to account B, this property ensures that at the end of successful transaction, changes in balance of these accounts are permanent (account A has balance of $90 and B has $110) and these changes don't get reversed in the case of failure.

Comments

Post a Comment

Popular posts from this blog

Working in India

The day I started working in SRA India(Indian arm of Japan's Software Research Associates, Inc ), I never thought that I world become an onsite team member in just one and half years. Because, the branch was very small & it was very illogical for a novice like me to think of an onsite tour that time. But the fact was that they would make you do your work in almost Japanese style. The very first day I started coding in SRA India, I was told that the Japanese were simply put - perfectionists. This simple word had a very large inner meaning. The code that you wrote should be totally bug free, robust, modifiable without introducing regression etc. The first project I was assigned to, it took a hell lot days to prepare only the detailed design(Java Doc) for a very tiny function, every molecular level detail was described on that. But somehow I made myself adjusted to such work environment. My performance was good in my batch. And in one day, one of my managers told me of an onsite a...
Post a Comment
Read more

Java collection series - miscellaneous

Java Vector is a legacy class. And it is significantly faster in comparison to a list obtained through Collections.synchronizedList(). Vector has loads of legacy operations and hence the manipulations in Vector needs to be done through the List interface, otherwise you won't be able to replace the implementation at a later time. Arrays.asList() is better choice if the list is of fixed size and any kind of size mutation of the collection results in UnsupportedOperationException. The underlying array is updated whenever the list is updated (or vice-versa), but the array reference isn't retained. Collections.nCopies() is another convenient mini-implementation which can be useful in two ways - initialize a newly created list with n null values (need not be only null values) -  new ArrayList (Collections.nCopies(1000, (Type)null)  grow an existing list -  lovablePets.addAll(Collections.nCopies(69, "fruit bat")) Collections.singleton()/Collectio...
Post a Comment
Read more