What are the problems that can occur if you do not implement locking properly in SQL SERVER?
The problems that occur if you do not implement locking properly in SQL SERVER is as follows:
Lost Updates:
The Lost updates occurs if you let two transactions change the same data at the same time, and the transaction which completes first is lost. You requireto watch out for the lost updates with the READ UNCOMMITTED isolation level. This isolation level disregards any type of locks, so two simultaneous data modifications are not aware of each other. Suppose that the customer has due of 2000$ to be paid. He paid 1000$ & again buys a product of 500$. Now say that these two transactions are now been entered from two different counters of the company. Now both counter user starts making entry at the same time 10:00 AM. Actually say at 10:01 AM the customer should have 2000$-1000$+500 = 1500$ pending to be paid. But as said in the lost updates the first transaction is not considered and the second transaction overrides it. So the final pending is 2000$+500$ = 2500$.....I hope the company does not loose the customer.
Non-Repeatable Read:
The Non-repeatable reads occurs if a transaction is able to read the similar row multiple times and gets a different value every time. Again, this problem is most likely to occur with the READ UNCOMMITTED isolation level. Because you let two transactions change data at the similar time, you can get some unexpected results. For an instance, a customer wants to book flight, so the travel agent checks for the flights availability. The Travel agent finds a seat and goes ahead to book the seat.While the travel agent is booking the seat, some another travel agent books the seat. When the travel agent goes to update the record, he gets error saying that "Seat is already booked". In brief the travel agent gets different status at the different times for the seat.
Dirty Reads:
The Dirty reads are a special case of non-repeatable read. This happens only if you run a report while transactions are changing the data that you're reporting on. For example there is a customer invoice report which runs on 1:00 AM in the afternoon and after that all invoices are sent to the respective customer for payments. Let us say one of the customer has 1000$ to be paid. The Customer pays 1000$ at 1:00 AM and at the same time report is run. Actually the customer has no money pending but is still issued an invoice.
Phantom Reads:
The Phantom reads occur due to a transaction being able to read a row on the first read, but not being able to change the same row due to another transaction deleting rows from the similar table. Lets say you edit a record in the mean time someone comes and deletes the record, you then go for updating the record which does not exist.Panicked. Interestingly, the phantom reads can occur even with the default isolation level supported by the SQL Server: READ COMMITTED. The only isolation level that doesn't allow phantoms is SERIALIZABLE, which assures that every transaction is completely isolated from others. In other words, no one can acquire any type of locks on the affected row while it is being changed.