To be serializable we need each transaction to

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: but if those locks have contention, things can be slow. So maybe do something optimistic: a sequence of versions of each bit of state, where transactions commit against a logically consistent set of versions (at a logical timestamp).] Analogy: source code version control. Take a snapshot of the state of the system, modify what you need, then check it back in – if in the meantime someone else has also modified it? Then restart from the new version. Maybe get unlucky again! Just keep trying. In approach 1, we needed a way to revert to the beginning of the transaction to deal with deadlock. This means we have to keep track of multiple versions of each file, so that we can revert correctly. Given that, maybe we can simplify things a bit? Suppose we let other nodes proceed with their reads and writes, without any locking. Then we can check at the point we do the commit, whether there is a conflict, and if so, roll that particular transaction back. What do I mean by “if there is a conflict”? To be serializable, we need each transaction to complete in a single order everywhere. One can think of transactions as committing in that order T1, T2 … Ti, Ti+1, … and so forth. We can commit Ti, provided that all of its reads and all of its writes are consistent with the state of the storage system at that time. So if we read a file, we need it to be the version of the file that is live after transaction Ti- 1. Why might this not be true? Well, if we...
View Full Document

This document was uploaded on 04/04/2014.

Ask a homework question - tutors are online