Starvation Vs Deadlock

Starvation	Deadlock
Starvation happens if same transaction is always choosen as victim.	A deadlock is a condition in which two or more transaction are waiting for each other.
It occurs if the waiting scheme for locked items in unfair, giving priority to some transactions over others.	A situation where two or more transactions are unable to proceed because each is waiting for one of the other to do something.
Starvation is also known as lived lock.	Deadlock is also known as circular waiting.
Avoidance: ->switch priorities so that every thread has a chance to have high priority. -> Use FIFO order among competing request.	Avoidance: ->Acquire locks are predefined order. ->Acquire locks at once before starting.
It means that transaction goes in a state where transaction never progress.	It is a situation where transactions are waiting for each other.
Example :	Example :

Lost Update Vs Uncommitted Data

Lost Update	Uncommitted Data
This problem is also known as “Multiple Update problem”	This problem is also known as “Dirty Read”
In the multiple update problem, the data written by one transaction is being overwritten by another transaction.	In Dirty read, data written by one transaction is read by another transaction before that transaction commits.
Two transaction accessing the same database item have their operations interleaved in a way that makes the database item incorrect.	This problem occurs when one transaction is allowed to see the intermediate result of the another transaction before it is committed.
Example : Connection A Connection B    ………    ……… SELECT Row1    ………    ………    ………    ……… SELECT Row1    ………    ……… UPDATE Row1    ………    ………    ………    ……… UPDATE Row1	Example : Connection A Connection B    ………    ………    ………  UPDATE Row1    ………    ……… SELECT Row1    ………    ………    ………    ………  ROLLBACK
Situation : Connection A and B both read a record and then update it, the effect of the first update will be overwritten by the second update.	Situation : Connection A reads an object that has been modified by Connection B but Connection B has not committed yet. Here, Connection B rollback transaction and uncommitted data is already read by Connection A. This is known as “Uncommitted Dependency”
Problem : Connection A and B both reading old value. Here Connection A updates row after some time Connection B updates that row. So, changes made by Connection A would be lost.	Problem : Connection A was permitted to read the intermediate result of Connection B before the Connection B was terminated.
Solution : Prohibit a shared lock Use batch processing Implementing locking scheme Two phase locking also solve this problem	Solution : Prevent Connection A from reading the account balance until the Connection B is terminated. i.e. either committed or rollback.

Serial Schedule Vs Non-Serial Schedule

Serial Schedule	Non-Serial Schedule
A serial schedule is a sequence of operation by a set of concurrent transaction that preserves the order of operations in each of the individual transactions.	A non-serial schedule is a schedule where the operations of a group of concurrent transactions are interleaved.
Transactions are performed in serial order.	Transactions are performed in non-serial order, but result should be same as serial.
No interference between transactions	Concurrency problem can arise here.
It does not matter which transaction is executed first, as long as every transaction is executed in its entirely from the beginning to end.	The problem we have seen earlier lost update, uncommitted data, inconsistent analysis is arise if scheduling is not proper.
A serial schedule gives the benefits of concurrent execution without any problem	In this schedule there is no any benefit of concurrent execution.
Serial schedule that does interleaved the actions of different transactions.	Where non-serial schedule has no only fix actions of any transaction.
EXAMPLE: If some transaction T is long, the other transaction must wait for T to complete all its operations.	EXAMPLE: In this schedule the execution of other transaction goes on without waiting the completion of T.
If we consider transaction to be independent serial schedule is correct based on (property ACID) above assumption is valid.	The objective behind serializability is to find the non-serial schedule that allows transactions to execute concurrently without interfering one another.

Dirty Read Vs Unrepeatable Read

Dirty Read	Unrepeatable Read
A dirty read problem occurs when one transaction updates a database item and then the transaction fails for some reason.	Unrepeatable read occurs when a transaction calculate some aggregate (summary) function over a set of data while other transaction are updating the data.
This problem is also known as “Un-Committed Data”	This problem is known as “Inconsistent Analysis”
The dirty read is consequence of reading updates made by a transaction before it has successfully finished	In, databases Read-Write Conflict, also known as unrepeatable reads, is a computational anomaly associated with interleaved execution of transactions.
Example : Connection A Connection B    ………    ………    ………  UPDATE Row1    ………    ……… SELECT Row1    ………    ………    ………    ………  ROLLBACK	Example : Connection A Connection B SELECT SUM(accounts) Acc[1]=40 Acc[1]=40 . . .  Sum = 40 Acc[2]=50 Acc[2]=50 . . .  Sum = 90 Acc[3]=30             . . . . . .   . . . . . .             . . . . . . UPDATE Acc3 = Acc3-10             . . . . . . (30 -> 20)             . . . . . . UPDATE Acc1= Acc1+10             . . . . . . (40 -> 50)             . . . . . . Commit Acc[3]=20 . . . Sum = 110 (It Should be 120)
Situation : Connection A reads an object that has been modified by Connection B but Connection B has not committed yet. Here, Connection B rollback transaction and uncommitted data is already read by Connection A. This is known as “Dirty Read”	Situation : Connection A performs aggregate sum of accounts, at same time Connection B modifies the database. This is resulted into Inconsistent Analysis
Problem : Transaction T2 was permitted to read the intermediate result of transaction T1 before the transaction T1 was terminated.	Problem of unrepeatable read occurs when a transaction reads a several values from database while other transaction updating those values.
Solution : Prevent T2 from reading the account balance until the transaction T1 is terminated. i.e. either committed or rollback.	Solution is prevent other transaction to read the values from the database until one transaction release it.