Microsoft Interview Question
InternsCountry: India
Suppose two joint account holders try to withdraw some amount at the same time.
The withdrawal process should be a critical section. The other person can specify his requirements (about how much to withdraw) and can even click on "OK" button to debit, but his machine shouldn't render any money as long as the first person's transaction is not complete and there is still enough money in account to cater second withdrawer's request.
The lock should be obtained as soon as "OK" button is clicked.
Most times, when you are worried about corruption due to two processes happening simultaneously, it is common to lock down the thread when the first process begins.In this case, I would design it so that when someone is making a withdrawal or deposit on the account, it would lock down the account (typically using a mutex of some sort) and limit the other user to only being able to view the balance or other things that don't actually change the state of the account. Also, for end user knowledge/experience, I would display a warning stating that this account is in use at another location and therefore, the balance may not be up to date. Once the first person was done, the account would be released so that the other user could then conduct their business
There are two ways of locking database - Pessimistic and Optimistic.
- Ashay Raut August 07, 2013Pessimistic used:
In the banking application example, an account is locked as soon as it is accessed in a transaction. Attempts to use the account in other transactions while it is locked will either result in the other process being delayed until the account lock is released, or that the process transaction will be rolled back. The lock exists until the transaction has either been committed or rolled back.
If Optimistic is used :
In the banking application example, the amount of an account is saved when the account is first accessed in a transaction. If the transaction changes the account amount, the amount is read from the store again just before the amount is about to be updated. If the amount has changed since the transaction began, the transaction will fail itself, otherwise the new amount is written to persistent.
I have taken this from wiki : Please read complete article from
wiki/Lock_(database)