Parting Shots

Our mantras in this chapter have been "Keep transactions short" and "Avoid conflict." Here are some ways to attain such ends.

Put calculations and validity tests before the transaction starts. That's an argument for doing some validation on the client.

End transactions. In many situations, saying CLOSE CURSOR isn't enough; for example, in read-only situations you can't depend on auto-commit . You should explicitly COMMIT or ROLLBACK, with whatever tool you're using.

Partition data so that volatile fields are in one place and changeless fields are in another. It's sufficient to follow the usual normalization rules.

Partition applications so that unlike operations are separated. For example, the employee reporting program has no need to access customer address data.

Replicate so that reporting transactions don't interfere with updating transactions.

Carry over information from one transaction to the next . For example, a typical library application gets the patron's ID once, then processes each book withdrawal as a separate transaction. There's no need to reread the patron record each time.

Assume the DBMS will initially give higher scheduling priority to the transaction with the lowest isolation level.