In the bullet point for "Isolation", does it imply that all the writes within an atomic session would commit right at the end of the atomic session, instead of on halfway?
yimmyz
@418_touhenying
Yes, that is right. For example, if we have the following transaction (literally a "transaction" too):
Deduce $30 from A's bank acct; Add $30 to B's bank acct;
Then, at any time in the universe, isloation means that we would either observe that A and B both have the original amount of money, or that they both have the new amount.
In the real world, of course, bank transactions are much more complicated than this, and a standard 2PC is performed.)
Fantasy
I am confused about why there are both atomicity and isolation? If atomicity holds true ("at commit, all memory writes take effect at once"), doesn't it imply isolation (no other code can observe write before commit)?
yimmyz
@Fantasy Well, the two are actually different, and the explanation of all-or-nothing on the slide is a bit misleading.
What atomicity enforces is "all-or-nothing", which means that it might allow a policy where, during a transaction, all writes are committed as they occur, and rollback of the entire sequence happens if something goes wrong. (This satisfies all-or-nothing, right?)
However, the policy above doesn't satisfy isolation, since if we have multiple such transactions being interleaved at the same time (as in modern DBMS), then the partial result of a transaction would be available to others. (Ideally, to guarantee isolation, we need to have some buffer to hold the modified the values of a transaction, and only commit them to the DB after everything completes successfully).
Does my explanation make sense?
arcticx
@yimmyz Do you mean that atomic just means "all-or-nothing" but its intermediate result can still be seen by other threads?
yimmyz
@arcticx Yup, that's right.
maxdecmeridius
What does serializablity mean?
What I took away from lecture is that every transaction in the system happens serially in some order, but doesn't that mean that we can't have simultaneous transactions? Wouldn't that significantly reduce the performance of a parallel system?
yimmyz
@maxdecmeridius Well, it means that the individual operations in transactions are ordered as if transactions happened in some serial order. Think instruction-lvl parallelism, where it fetches independent instructions to run simultaneously, but as software developer we think the execution is sequential. In the context of a database, transactions to different tables / shards might also be interleaved simultaneously. Does it make sense?
maxdecmeridius
@yimmyz Yeah that makes more sense. its more like the results of the transactions are serialized, but the computation for those results can be parallel, right?
yimmyz
@maxdecmeridius Yep, that's exactly what I was talking about.
In the bullet point for "Isolation", does it imply that all the writes within an atomic session would commit right at the end of the atomic session, instead of on halfway?
@418_touhenying
Yes, that is right. For example, if we have the following transaction (literally a "transaction" too):
Then, at any time in the universe, isloation means that we would either observe that A and B both have the original amount of money, or that they both have the new amount.
In the real world, of course, bank transactions are much more complicated than this, and a standard 2PC is performed.)
I am confused about why there are both atomicity and isolation? If atomicity holds true ("at commit, all memory writes take effect at once"), doesn't it imply isolation (no other code can observe write before commit)?
@Fantasy Well, the two are actually different, and the explanation of all-or-nothing on the slide is a bit misleading.
What atomicity enforces is "all-or-nothing", which means that it might allow a policy where, during a transaction, all writes are committed as they occur, and rollback of the entire sequence happens if something goes wrong. (This satisfies all-or-nothing, right?)
However, the policy above doesn't satisfy isolation, since if we have multiple such transactions being interleaved at the same time (as in modern DBMS), then the partial result of a transaction would be available to others. (Ideally, to guarantee isolation, we need to have some buffer to hold the modified the values of a transaction, and only commit them to the DB after everything completes successfully).
Does my explanation make sense?
@yimmyz Do you mean that
atomicjust means "all-or-nothing" but its intermediate result can still be seen by other threads?@arcticx Yup, that's right.
What does serializablity mean?
What I took away from lecture is that every transaction in the system happens serially in some order, but doesn't that mean that we can't have simultaneous transactions? Wouldn't that significantly reduce the performance of a parallel system?
@maxdecmeridius Well, it means that the individual operations in transactions are ordered as if transactions happened in some serial order. Think instruction-lvl parallelism, where it fetches independent instructions to run simultaneously, but as software developer we think the execution is sequential. In the context of a database, transactions to different tables / shards might also be interleaved simultaneously. Does it make sense?
@yimmyz Yeah that makes more sense. its more like the results of the transactions are serialized, but the computation for those results can be parallel, right?
@maxdecmeridius Yep, that's exactly what I was talking about.