What are desirable properties of transactions? Explain conflict serializability with example.

A transaction is a group of database operations that form one logical unit of work, such as transferring money between two accounts. The desirable properties are ACID:

• Atomicity: either all operations of the transaction are done, or none are. A failed transfer must not debit one account without crediting the other.
• Consistency: a transaction takes the database from one valid state to another; all constraints still hold afterwards.
• Isolation: concurrent transactions do not see each other's incomplete work; the result is as if they ran one after another.
• Durability: once a transaction commits, its changes survive crashes and power failures.

Conflict serializability

Two operations conflict if they belong to different transactions, act on the same data item, and at least one of them is a write (R–W, W–R or W–W).

A schedule is conflict serializable if it can be turned into a serial schedule by swapping adjacent non-conflicting operations. It is tested with a precedence graph:

1. Draw a node for each transaction.
2. For every conflicting pair where Ti's operation comes before Tj's, draw an edge Ti → Tj.
3. If the graph has no cycle, the schedule is conflict serializable.

Example

Every conflict on A and on B has T1's operation first, so the only edge is T1 → T2. There is no cycle, so the schedule is conflict serializable, and it is equivalent to the serial schedule T1 then T2.

If instead T2 wrote B before T1 read B, we would also get the edge T2 → T1. The cycle T1 → T2 → T1 would make the schedule not conflict serializable.