fractal's Qualifier
Player:
Event:
Tournament:
Status:
Approved
Score:
3,477,000
Total score:
3,477,000
Details:
2. Transactions, Locking, and Concurrency Control
Before starting, you should make sure you understand what a transaction is and how strict two-phase locking (which you will use to ensure isolation and atomicity of your transactions) works.
In the remainder of this section, we briefly overview these concepts and discuss how they relate to GoDB.
2.1. Transactions
A transaction is a group of database actions (e.g., inserts, deletes, and reads) that are executed atomically; that is, either all of the actions complete or none of them do, and it is not apparent to an outside observer of the database that these actions were not completed as a part of a single, indivisible action.
In GoDB, and most database systems, each transaction runs in a separate thread. This means that there can concurrently be multiple threads attempting to invoke methods on the database. You will need to use mutexes or other synchronization primitives to prevent these concurrent threads from experiencing race conditions that may result in indeterminate behavior.
2.2. The ACID Properties
To help you understand how transaction management works in GoDB, we briefly review how it ensures that the ACID properties are satisfied:
Atomicity: Strict two-phase locking and careful buffer management ensure atomicity.
Consistency: The database is transaction consistent by virtue of atomicity. Other consistency issues (e.g., key constraints) are not addressed in GoDB.
Isolation: Strict two-phase locking provides isolation.
Durability: A FORCE buffer management policy ensures durability (see Section 2.3 below).
2.3. Recovery and Buffer Management
To simplify your job, we recommend that you implement a NO STEAL/FORCE buffer management policy.
As we discussed in class, this means that:
You shouldn't evict dirty (updated) pages from the buffer pool if they are locked by an uncommitted transaction (this is NO STEAL). Your buffer pool implementation already does this.
On transaction commit, you should force dirty pages to disk (e.g., write the pages out) (this is FORCE).
To further simplify your life, you may assume that GoDB will not crash while processing a CommitTransaction or AbortTransaction command. Note that these two points mean that you do not need to implement log-based recovery in this lab since you will never need to undo any work (you never evict dirty pages), and you will never need to redo any work (you force updates on commit and will not crash during commit processing).