Is it assumed that lazy versioning is always paired with optimistic detection, and eager with pessimistic? If not, it seems as though the examples in the following slides would not necessarily hold true.
randomized
I think lazy versioning can be paired with pessimistic detection. Please look at slide 52.
doodooloo
Is a normal read/write considered a conflict with a transaction?
bmperez
@doodooloo It depends on what you mean by a "normal read/write". Obviously, if you're talking about only a single processor, then no, it is not conflict. Transactions are required to happen in isolation. This means that no writes from a given transaction should be visible to other transactions until all writes from the transaction are visible. Equivalently, no writes should be visible to other transactions until this transaction commits.
With this in mind, let's say you have two processors P0 and P1, which are both in the process of running a transaction. A read and write can only conflict in the case that the read occurs after the write. Let's also say we have an address A both P0 and P1 are interacting with. If P0 reads A, and then P1 writes to A, then we're good because P1's write has not become visible to another transaction before commit-time. However, if P1 writes to A, and then P0 reads, then we will have a conflict because P0 has "seen" P1's write before all of P1's writes were visible, or before its commit-time. Thus, in this case, we have a conflict because the isolation invariant was violated, so we must abort the transaction.
Is it assumed that lazy versioning is always paired with optimistic detection, and eager with pessimistic? If not, it seems as though the examples in the following slides would not necessarily hold true.
I think lazy versioning can be paired with pessimistic detection. Please look at slide 52.
Is a normal read/write considered a conflict with a transaction?
@doodooloo It depends on what you mean by a "normal read/write". Obviously, if you're talking about only a single processor, then no, it is not conflict. Transactions are required to happen in isolation. This means that no writes from a given transaction should be visible to other transactions until all writes from the transaction are visible. Equivalently, no writes should be visible to other transactions until this transaction commits.
With this in mind, let's say you have two processors P0 and P1, which are both in the process of running a transaction. A read and write can only conflict in the case that the read occurs after the write. Let's also say we have an address A both P0 and P1 are interacting with. If P0 reads A, and then P1 writes to A, then we're good because P1's write has not become visible to another transaction before commit-time. However, if P1 writes to A, and then P0 reads, then we will have a conflict because P0 has "seen" P1's write before all of P1's writes were visible, or before its commit-time. Thus, in this case, we have a conflict because the isolation invariant was violated, so we must abort the transaction.