1 / 6

CSC 556 – DBMS II, Spring 2013

CSC 556 – DBMS II, Spring 2013. May 1, 2013 DBMS ACID Properties & Concurrency Control. DBMS ACID properties. Atomicity = transaction is all or none. Consistency ensures database integrity. Isolation avoids interaction of concurrent processes interacting with the database.

gil
Download Presentation

CSC 556 – DBMS II, Spring 2013

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSC 556 – DBMS II, Spring 2013 May 1, 2013 DBMS ACID Properties & Concurrency Control

  2. DBMS ACID properties • Atomicity = transaction is all or none. • Consistency ensures database integrity. • Isolation avoids interaction of concurrent processes interacting with the database. • Durability ensures persistence in the face of crashes, power losses and errors.

  3. FileMultiSet ACID support • Uses expensive SYNC flag to force flushes. • recoveryFile gets a sequential SYNC’d copy of each mutation before mutating main DB. • transact() sets a transaction boundary. • docommit() cleans up recovery records. • dorollback() reads records from recovery file & restores state of main DB. • A crash occurring during a transaction or during a rollback still has recovery records in recovery file to affect repair. • LockedFileMultiSet uses expensive file locking for concurrency control.

  4. More efficient transaction support • Serialize access to DB files via server process or synchronized server processes. • This approach avoids expensive file I/O locks. • http://docs.oracle.com/cd/E11882_01/server.112/e16508/intro.htm • http://www.siue.edu/~dbock/cmis565/module1-architecture.htm • Data versioning notes timestamp at start of transaction. At time of commit, if timestamp of data has changed, roll back and redo.

  5. Functional programming approach • No data structure is ever mutated. • Construct new tuples and abandon references to their predecessors. • Eventually garbage collect 0-reference tuples. • Use lazy evaluation to defer repeated small changes to data structures. Perform mutations in batches the first time they must be read. • Indices (B-trees) must still be mutated.

  6. Concurrency control • Timestamps / version numbers applied upwards from data records through B-tree. • These establish oldest records in a subtree. • Timestamps / version numbers applied downwards from root to data records during lookup-preceding-mutation. • These establish newest records in a subtree. • Use as a basis for tentative updates requiring rollback and restart when initial query data change during a transaction.

More Related