As an example, if two people are updating the same catalog item, it's not acceptable for one person's changes to be "clobbered" when the second person saves a different set of changes. Both users should be able to work in isolation, working as though he or she is the only user. Each set of changes must be isolated from those of the other users.
An important concept to understanding isolation through transactions is serializability. Transactions are serializable when the effect on the database is the same whether the transactions are executed in serial order or in an interleaved fashion. As you can see at the top of the figure, Transactions 1 through Transaction 3 are executing concurrently over time. The effect on the DBMS is that the transactions may execute in serial order based on consistency and isolation requirements. If you look at the bottom of the figure, you can see several ways in which these transactions may execute. It is important to note that a serialized execution does not imply the first transactions will automatically be the ones that will terminate before other transactions in the serial order.
Degrees of isolation¹:
* degree 0 - a transaction does not overwrite data updated by another user or process ("dirty data") of other transactions
* degree 1 - degree 0 plus a transaction does not commit any writes until it completes all its writes (until the end of transaction)
* degree 2 - degree 1 plus a transaction does not read dirty data from other transactions
* degree 3 - degree 2 plus other transactions do not dirty data read by a transaction before the transaction commits
No comments:
Post a Comment