Consider the following transaction involving two bank accounts $x$ and $y$.
read(x); x:=x-50; write (x); read(y); y:=y+50; write(y)
The constraint that the sum of the accounts $x$ and $y$ should remain constant is that of
Sachin Mittal 1 shots fired, shots fired.
Why can't we go with option durability?
As per question The sum of account x and y should remain constant .
So even if there is some failure the values should not change and final values should be retained. So I beleive answer might be durability.
Some one please correct me if my understanding is wrong.
Transaction to transfer $50 from account A to account B:
once the user has been notified that the transaction has completed (i.e., the transfer of the $50 has taken place), the updates to the database by the transaction must persist even if there are software or hardware failures.
(in above example) the sum of A and B is unchanged by the execution of the transaction.
In general, consistency requirements include
Explicitly specified integrity constraints such as primary keys and foreign keys.
Implicit integrity constraints- e.g. sum of balances of all accounts, minus sum of loan amounts must equal value of cash in hand.
A transaction must see a consistent database.
During transaction execution the database may be temporarily inconsistent.
When the transaction completes successfully the database must be consistent.
Erroneous transaction logic can lead to inconsistency
if between steps 3 and 6, another transaction T2 is allowed to access the partially updated database, it will see an inconsistent database (the sum A + B will be less than it should be).
Isolation can be ensured trivially by running transactions serially.
@Lakshman Patel RJIT sir plz update the link as it’s not working