similarly if you are implementing a file system and

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: safe to read the results of a transaction after the commit occurs. With locking, you might need to worry about deadlock – e.g., in the case above, we can deadlock if we acquire the locks as we need them. Here’s the great thing about transactions: Can always break a deadlock by aborting one of the waiting transactions. If we revert back to the start, we can then retry. [Note! This means that a transaction can abort, due to no fault of its own! So your implementation needs to handle that case.] Similarly, if you are implementing a file system, and somewhere inside a file system operation, you find that there’s no free block so you can’t complete the operation (e.g., for a file move)? Transactions give you a structured way to handle exceptions, in the presence of durable storage. <anecdote about friend at the terminal> Solution? Write new file, then delete old file, so you can back out if there’s a problem. Never overwrite important data. [If we batch commits, then we might want to allow the second transaction to start without waiting for the commit. To be precise, its ok to allow one transaction to read the results of another, if we ensure that they are chained – that it will abort if the first one aborts.] Approach 2: Optimistic concurrency control (spiffier, and how we suggest you do the assignment) [Synopsis of approach 2: With two phase locking, locks are held during the entire commit procedure. Logically that’s ok,...
View Full Document

This document was uploaded on 04/04/2014.

Ask a homework question - tutors are online