CSCI 5433 Object Oriented Database Systems Presentation id

CSCI 5433 - Object Oriented Database Systems Presentation id# 3 Sai Abhilash Uppuluri Pages (~235 to 247)

Contents • Concurrent Transactions • Isolation Level • Collisions • Collision detection • Collision Avoidance with Semaphores • Failure and Durability

Concurrent Transactions: • In standalone mode, only one client can access a database file at a time • In client/server mode, on the other hand, there may be more than one transaction acting concurrently on a single database • The transactions may be initiated by clients in separate threads in an embedded server environment, or by separate network clients in a network server environment

Isolation Level: • The isolation between concurrent transactions becomes an important issue in these situations • With concurrent transactions, there is the possibility that one transaction may try to read or modify an object in the database during the lifetime of another transaction that is also acting on that object • A strategy is required so that the database knows what to do in this situation. The strategy is known as the isolation level. Isolation is one of the ACID properties.

Isolation levels revisited: • The 4 commonly used isolation levels are: This means that there is effectively no locking, except while a transaction is actually being committed Read Uncommitted: This uses optimistic locking, and allows one transaction to read data that has been modified and committed by another concurrent transaction Read Committed: These use more pessimistic locking to prevent unrepeatable reads and provide a greater degree of isolation Repeatable Read and Serializable:

Isolation in db 4 o: • db 4 o takes a very straightforward approach: All transactions are Read Committed. It is possible to enforce stricter locking explicitly in your application if necessary Looking at Transaction Isolation:

Collisions: • What if client 2 doesn’t just read the data, but also updates it? To simulate this collision situation, the following code can be inserted immediately after the queries on client 2, so that client 2 is attempting to record a payment of $50 at the same time as client 1 is recording a payment of $100. client 2 commits update only at the end of its transaction

Collision Detection: • The basic idea of collision detection is to check before committing a transaction that the object in the database has not changed since the transaction started

Collision Avoidance with Semaphores: • Collisions can be avoided with db 4 o by explicitly locking objects during a transaction rather than relying on the database’s own locking strategy • One way of doing this is to use semaphores • Once a particular semaphore is set out, any attempts to set a semaphore with the same name will fail until the first client releases it.

Failures and Durability: • The one ACID property we haven’t discussed much is durability, which requires that any data that has been committed to the database must not be lost. • This is straightforward after commit: db 4 o database files can easily be backed up, or the data can be replicated

Thank You