8. Transactions

A transaction is issued using constructs: (these are the only ones we need for discussion of Concurrency Control and Recovery - the DBMS issues discussed in this section).

BEGIN to initiate a transaction (most actual system supply the BEGIN if the user doesn't, e.g., whenever a new SQL statement is encountered it is assumed to iniate a new transaction)

END to end a transaction (usually either COMMIT for successful END and ABORT for unsuccessful END) (most actual system supply this element if the user doesn't, e.g., If SQL statement execution is successful, Then DBMS supplies COMMIT, else ABORT)

READ whenever any data is needed from the DB (e.g., in an SQL SELECT) WRITE whenever any data needs to be written to the DB (e.g., in an SQL INSERT or UPDATE) In this set

of notes, all others aspects of language, coding, etc. will be considered as un-intrepreted aspects.

Section 8 # 1

The terminology used in this section is that all users (online interactive users or batch programs) issue transactions to the DBMS. A TRANSACTION is an atomic unit of database work specified by a user to the DBMS (atomic means - either executed to completion or not executed at all). Transactions are often called QUERIES when they request only read access (i.e., QUERIES are READ-ONLY TRANSACTIONS).

When a transaction arrives at the DBMS, a Transaction Manager (TM) is assigned to it (code segment to act on its behalf). The TM interfaces with other components, e.g., the Scheduler (SCHED) for permission to access particular data items. SCHED is like a policeman, giving permission to access the requested item(s). Its activity is called concurrency control.

Once permission is granted for TM to access data items Data Manager (DM) does the actual reads and writes. There are several models for describing this interaction. We will describe two of them, Model-1 and Model-2.

Transactions Processing, Model-1

Transaction Manager(s)1. TM makes requests to the SCHEDULER

to read/write data item(s) or to commit/abort the transaction

There can be one TM multithreaded by all transactions, or an individual TM assigned to each individual transaction.

Scheduler

Data Manager

Data on Disk

5; read value, write/commit ack1. read, write,

commit, abort

4 value read;write/commit_ack2. read, write,

commit, abort

3. read, write,

2. Scheduler (SCHED) decides if the request can be scheduled . If yes, it schedules request (passes it to DM (on TMs behalf). If no rejects it, informs TM.

3. DM read/writes the data item or commits or aborts the transaction if possible, else returns reject to the SCHEDULER (which returns it to TM)

4. DM returns the value read (or returns an acknowledgement(ACK) of the write or commit request to the SCHEDULER

5. SCHED returns the same to the TM.

2 ,3; reject

Section 8 # 2

3 reject.

Transactions Processing, Model-2

(assumed through the rest of notes)

Transaction Manager(s)1. TM requests permissions from SCHED.

There can be one TM multithreaded by all transactions, or an individual TM assigned to each individual transaction.

Scheduler

Data Manager

Data on Disk

1. read, write, commit, abort

5. value read or ack reject

3. read, write, commit, abort

4. read, write,

2. SCHED accepts or rejects TMs permission requests.

4. DM read/writes the data item or commits or aborts the transaction if possible, else returns reject to the TM.

5. DM returns the value read (or returns an acknowledgement(ACK) of the write or commit request to the TM

2. decision:accept orreject

3. TM requests DM to do read/write/commit/abort.

Section 8 # 3

Concurrency Control (CC) (the activity of the scheduler, SCHED) We need concurrency control (AKA mutual exclusion) whenever there are shared system

resources that cannot be used concurrently. An illegal concurrent use of a shared resource is a conflict. E.g., one user reads JONES while

another user changes JONES to SMITH. The read could get SMIES.The shared DBMS resources will be call data items.DATA ITEM GRANULARITY is the level at which we treat Concurrency Control:

field level (logical level, very fine granularity) record level (logical level, fine granularity) page level (physical level, medium granularity) file level (logical level, coarse granularity) area level (logical level, quite coarse granularity) database level (logical level, very coarse granularity)

We assume, that a data item is a record (i.e., we assume logical, record-level granularity)

This means there are many more shared resources for DBMS to manage than anywhere else, (e.g., printers for an O/S), and thus, CC is harder in a DBMS than anywhere else!

A DBMS may have 1,000,000 records or more. An O/S may have to manage ~ 50 printers.

Ethernet Medium Access Protocol (unswitched) manages ONE shared wire.

Although you may have studied mutual exclusion before (e.g., in an Operating Systems course it is a more complicated problem in DBMS.

Section 8 # 4

Concurrency Control cont. In any resource management situation (Operating System, Network Operating System or DBMS...) there are

"shared resources" and there are "users". SHARED RESOURCE MANAGEMENT deals with how the system can insure correct access to shared resources among concurrently executing transactions?

All answers seem to come from traffic control! (traffic intersections, construction zones, driveup windows).

WAITING POLICY: If a needed resource is unavailable, requester waits until it becomes available (e.g., intersection red light, Hardee's drive up lane). This is how print jobs are managed by an OS.

Advantages: NO RESTARTING (no unnecessary progress loss) e.g., At Hardees, they don't say "Go home! Come back later! Disadvantages: DEADLOCKS may happen unless they are managed. E.g., at a construction zone, if the two flag women don't coordinate, both traffic lines may start into construction zones from opposite directions resulting in a DEADLOCK in the middle!). Another disadvantage is INCONSISTENT RESPONSE TIMES. At the Hardees window, you may wait an hour or a minute. (Not so important at Hardees (well maybe it is if you're very hungry? ;-), but at an Emergency Room?).

RESTART POLICY: If a needed resource is unavailable, the request is terminated and restarted later. E.g., When someone goes before a parole board, they either get their request or they restart the process later).

In Ethernet (unswitched) CSMA/CD, if node A wants to send a message to node B:

1. Carrier Sense (the "CS" part): the wire is checked for traffic; if it is busy (in use by another sender), A waits (according to some "back-off algorithm") then checks again, etc. until the wire is idle, then SENDs the message.

2. Collision Detection (the "CD" part): listen to bus until you're certain that your message did not collide with another concurrently sent message (the required length of wait time is the traversal_time of wire, since there are terminators (absorbers) at each end).

Advantages of restart policies: simple, no deadlock

Disadvantages: Lower throughput, lost progress, long delays?, possible livelock. Section 8 # 5

Concurrency Control cont. A Transaction is an atomic computation or program taking the database from one consistent

state to another (without necessarily preserving consistency at each step of the way).

The transaction is an atomic unit of database work, ie, DBMS executes transaction to completion or not at all, GUARANTEED. If only one transaction is allowed to execute at time and if the database starts in a consistent state then it will always end up in a consistent state! The problem with such a SERIAL EXECUTION policy is that it is too inefficient!

A DBMS must guarantee the so-called ACIDS PROPERTIES of transactions:

ATOMICITY: A transaction is an all-or-nothing proposition. Either a transaction is executed by the DBMS to completion or all of its effects are erased completely. (Transaction = atomic unit of database workload).

CONSISTENCY: Correct Transactions take the database from one consistent state to another consistent state. Consistency is defined in terms of consistency constraints or "integrity constraints", e.g., entity integrity, referential integrity, other integrities.

ISOLATION: Each user is given the illusion of being the sole user of the system (by the concurrency control subsystem).

DURABILITY: The effects of a transaction are never lost after it is "committed" by the DBMS. (ie, after a COMMIT request is acked by DBMS).

Section 8 # 6

Execution types SERIAL EXECUTION insures most of the ACID properties (Consistency and

isolation for sure. It also helps in atomicity and durability). i.e., queue all transactions as they come in (into a FIFO queue?). Let each transaction execute to completion before the next even starts. Serial execution may produce unacceptable execution delays (i.e., long response times) and low system utilization.

SERIALIZABLE EXECUTION is much, much better! Concurrent execution of multiple transactions is called serializable if the effect of the execution of operations (reads and writes) within the transactions are sequenced in a way that the result is equivalent to some serial execution (i.e., is as if it was done by a serial execution of transaction operations). Serializability facilitates ATOMICITY, CONSISTENCY and ISOLATION of concurrent, correct transactions, just as well as SERIAL does, but allow much higher system throughput.

RECOVERABILITY facilitates DURABILITY (more on this later). An execution is RECOVERABLE if every transactions that commits, commits only after every

other transaction it read-from is committed. Section 8 # 7

Isolation Levels SQL defines execution types or levels of isolation weaker than SERIALIZABILITY

(they do not guarantee ACIDS properties entirely, but they are easier to achieve).

REPEATABLE READ ensures that no value read or written by a transaction, T, is changed by any other transaction until T is complete; and that T can read only changes made by committed transactions.

READ COMMITTED ensures that no value written by a transaction, T is changed by any other transaction until T is complete; and that T can read only changes made by committed transactions.

READ UNCOMMITTED ensures nothing (T can read changes made to an item by an ongoing trans and the item can be further changed while T is in progress.

There will be further discussion on these later in these notes. For now, please note there are several suggested paper topics in the topics file concerning isolation levels. But also note that I think these other isolation levels are bunk!

Section 8 # 8

Concurrent Transactions are transactions whose executions overlaps in time (the individual operations

(read/write of a particular data item) may be interleaved in time). Again, the only operations we concern ourselves with are BEGIN, READ, WRITE, COMMIT, ABORT.

READ and WRITE are the operations that apply to data items. A data item can be a field, record, file, area or DB (logical granules) or page (physical granule). We assume record-level granularity.

A read(X) operation, reads current value of the data item, X, into a program variable (which we will also called X for simplicity). Even though we will not concern our selves with these details in this section, read(X) includes the following steps: 1. Find the address of the page containing X. 2. Copy that page to a main memory buffer (unless it is already in memory). 3. Copy the value of the dataitem, X, from the buffer to the program variable, X

The write(X) operation, writes the value of the program variable, X, into the database item X. It includes the following steps: 1. Find the address of the page containing X 2. Copy that page to a main memory buffer (unless it is already in memory). 3. Copy the program variable, X, to buffer area for X. 4. Write the buffer back to disk (can be deferred and is governed by DM).

Section 8 # 9