Transaction Processing and Con Currency Control

Advanced Database Systems Chapter-II

Transaction Processing and Concurrency Control

Basics of Database TransactionsTransaction processing involves the operating side of databases. Whereas

operations management describes how physical goods are produced, transaction management describes how information of goods or transactions is controlled. Transaction management, like management of physical goods is enormously important to modern organization. Organization such as banks with automatic tellers, airlines with on-line reservation and universities with on-line registration could not function without reliable and efficient transaction processing. In common discourse, a transaction is a interaction among two or more for the conduct of business such as buying a car from a dealership. Transactions for DBMSs have a more precise meaning. A database transaction involves a collection of operations that must be processed as one unit of work. Transactions should be processes reliably so that there is no loss of data due to multiple users and system failures. To help you grasp this more precise meaning, this section presents examples of transactions and defines properties of transactions.

Transaction ExamplesA transaction is a user-defined concept. For example, making an airline

reservation may involve reservations for the departure and return. To the user, the combination of the departure and the return is a transaction, not the departure and the return separately. Most travelers do not want to depart without returning. The implication for DBMSs is that a transaction is a user-defined set of database operations. A transaction can involve any number of reads and writes to a database. To provide the flexibility of user-defined transactions, DBMSs cannot restrict transactions to only a specified number of reads and writes to a database.

An information system may have many different kinds of transactions. The following table depicts transactions of an order entry system.

Transaction Kind DescriptionAdd order Customer places a new orderUpdate order Customer changes details of an existing orderCheck status Clerk reports the status of an order to customerPayment Payment received from customerShipment Goods sent to customer

Table: Typical Transactions in an Order Entry System

SQL Statements to Define TransactionsTo define transaction, we can use some additional statements. The figure depicts

additional SQL statements to define the prototypical automatic teller machine (ATM) transaction. The BEGIN TRANSACTION and COMMIT statements define the statements in the transaction. Any other SQL statements between them are part of the transaction. Typically, a transaction involves a number of SELECT, UPDATE, INSERT, DELETE statements.

Samuel Giftson, Dept of Computing, COE, MU 1

Besides the BEGIN TRANSACTION and COMMIT statements, the ROLLBACK statement may be used. It is like an undo command in a word processor. ROLLBACK causes all effects of a transaction to be removed. The database restored to the state before the transaction was executed. One situation for issuing a ROLLBACK statement is to allow the user to cancel a transaction. It can also be used as a part of exception handling statements such as the “On-Error”.

Transaction PropertiesDBMSs ensure that transactions obey certain properties. The most important

properties are ACID properties (Atomic, Consistent, Isolated and Durable). Atomic means that a transaction can’t be subdivided. Either all the work in the

transaction is completed or nothing is done. For example, the ATM transaction will not debit an account without also crediting a corresponding account.

Consistent means that if applicable constraints are true before the transaction starts, the constraints will be true after the transaction terminates. For example, if a users account is balanced before a transaction, then the account is balanced after the transaction. Otherwise, the transaction is rejected and no changes take effect.

Isolated means that changes resulting from a transaction are not revealed to other users until the transaction terminates. For example, your significant other will not know that you are withdrawing money until your ATM transaction completes.

Durable means that any changes resulting from a transaction are permanent. No failure will erase any changes after a transaction terminates. For example, if a banks computer experiences a failure seconds after your transaction completes the result of your transaction are still recorded on the bank database.

To ensure that, transactions meet the ACID properties, DBMSs provide certain services that are transparent to database developers and programmers. The DBMSs transparency means that the inner details of the transaction services are invisible. Transparency is important because services that ensure ACID transactions are very


BEGIN TRANSACTIONDisplay greetingGet account number, pin, type, and amountSELECT account number, type, and balanceIf balance is sufficient then

UPDATE account by posting debitUPDATE account by posting creditINSERT history recordDisplay final message and issue cash

ElseWrite error message

End IfOn Error: ROLLBACK

COMMIT

difficult to implement. DBMS provide two services, recovery transparency and concurrency transparency to ensure that transactions obey the ACID properties.

Recovery transparency means that the DBMS automatically restores a database to a consistent state after a failure. For example if a communication failure occurs during an ATM transaction, the effects of the transaction are automatically removed from the database. On the other hand, if the DBMS crash three seconds after an ATM transaction is completed, the effects of the transaction are still remaining on the database.

Concurrency Transparency means that users perceive the database as a single user system even though there may be many simultaneous users. For example, even though many users may try to reserve a popular flight using a reservation transaction, the DBMS ensures that users do not overwrite each other’s work.

Even though the inner details of concurrency and recovery are not visible to a user, these services are not free. Recovery and concurrency involve overhead that may adversely impact performance or require additional resources to reach an acceptable level of performance. The database designers must be aware of the resource implications of these services.

Transaction StateIn the absence of failure, all transactions complete successfully. However, as we noted earlier, a transaction may not always complete its execution successfully. Such a transaction is termed aborted. If we are to ensure the atomicity property, an aborted transaction must have no effect on the state of the database. Thus, any changes that the aborted transaction made to the database must be undone. Once the changes caused by an aborted transaction have been undone, we say that the transaction has been rolled back. It is the part of the recovery scheme to manage transaction aborts.

A transaction that completes its execution successfully is said to be committed. A committed transaction that has performed updates transforms the database into a new consistent state, which must persist even if there is a system failure.

Once a transaction has committed, we cannot undo its effects by aborting it. The only way to undo the effects of a committed transaction is to execute a compensation transaction. For Ex: if a transaction added 100$ to an account, the compensation transaction would subtract 100$ from the account. However, it is not always to create such a compensation transaction. Therefore, the responsibility of writing and executing a compensation transaction is left to the user and it is not handled by the database system.A transaction must be in one of the following states:

Active: The initial state, the transaction stays in this state while it is executing. Partially Committed: After the final statement has been executed. Failed: After the discovery that normal execution can no longer proceed. Aborted: After the transaction has been rolled back and the database has been

restored to its state prior to the start of the transaction. Committed: After Successful Completion.


The state diagram for the above states

A transaction is committed only if it has entered the committed state. Similarly, a transaction has aborted only if it has entered the aborted state. A transaction is said to have terminated if has either committed or aborted.A transaction starts in the active state. When it finishes its final statement, it enters the partially committed state. At this point the transaction has completed its execution, but it is still possible that it may have to be aborted, since actual output may still be temporarily residing in main memory and thus a hardware failure may preclude its successful completion.

The database system then writes out enough information to disk that, even in the event of a failure, the updates performed by the transaction can be re-created when the system restarts after the failure. When the last of this information is written out, the transaction enters the committed state.

A transaction enters the failed state after the system determines that the transaction can no longer proceed with its normal execution (because of hardware or logical errors). Such a transaction must be rolled back. Then, it enters the aborted state. At this point, the system has two options:

It can restart the transaction, but only if the transaction was aborted as a result of some hardware or software error that was not created through the internal logic of the transaction. A restarted transaction is considered to be a new transaction.

It can kill the transaction. It usually does so because of some internal logical error that can be corrected only by rewriting the application program, or because the input was bad, or because the desired data were no found in the database.

Concurrency ControlMost organizations cannot function without multi-user databases. For example,

airline, banking can have thousands of users simultaneously trying to conduct business.


Active

Failed Aborted

Committed

Part. Committed

Multiple users can access these databases concurrently, that is at the same time. However, concurrent user cannot be permitted to interfere with each other. Objective of Concurrency Control

The objective of the concurrency control is to maximize transaction throughput while preventing interference among multiple users. Transaction throughput, the number of transactions processed per unit time, is a measure of the amount of work performed by a DBMS. Typically, transaction throughput is reported in transactions per minute. From the perspective of the user, transaction throughput is related to the response time. High transaction throughput means lower response time. If there is no interference, the result of executing concurrent transactions is the same as executing the same transactions in some sequential order. Executing transactions sequentially would result in a low throughput and high waiting times. Thus, DBMS allowed transaction to execute simultaneously while ensuring the result are same as though executed sequentially. Transaction executing simultaneously cannot interfere unless they’re manipulating common data. Most concurrent transactions manipulate only small amount of common data. A hotspot is common data that multiple users try to change simultaneously. A hotspot represents a resource that the users must queue to access. Typically, hotspot are the seats remaining for popular flights the quantity on hand of popular inventory items etc. interference on hotspots can lead to last data and poor decision making. The following section describes interference problems and tools to prevent them.

Interference problemsThere are three problems that can result because of simultaneous access to the

database:1. Lost update2. Uncommitted dependency3. Incorrect summary

1. Lost UpdateThis is the most serious interference problem because changes to databases are

inadvertently lost. In a lost update, one users update overwrites another user update, which is depicted by the time line as below:

Figure: Example Lost Update Problem


Transaction A Time Transaction B

Read SR(10) T1

T2 Read SR(10)

If SR > 0 then SR = SR-1 T3

T4 If SR > 0 then SR = SR-1

Write SR(9) T5

T6 Write SR(9)

The timeline shows two concurrent transactions trying to update the seats remaining (SR) field of the same flight record. Assume that the value of SR is 10 before the transaction begin. After time T2 both transactions have stored the value of 10 for SR in local buffers. After time T4 both transactions have made changes to their local copy of SR. however, each transaction changes the value to 9, unaware the activity of the other transaction. After time T6, the value of SR on the database is 9. But the value after finishing both transactions should be 8 not 9, one of the changes has been lost. Some students become confused about the lost update problem because of the actions performed on local copies of the data. The calculations at times T3 and T4 are performed in memory buffers specific to each transaction. Even though transaction A has changed the value of SR, transaction B performs the calculation with its own local copy of SR having a value of 10. The write operation performed by transaction A is not known to transaction B unless transaction B reads the value again. A lost update involves two or more transactions trying to change the same part of the database.

2. Uncommitted Dependency It occurs when one transaction reads data written by another transaction before

other transaction commits. It is also known as dirty read because it is caused by one transaction reading dirty data. In the figure, transaction A reads the SR fields, changes its local copy of the SR field, and writes the new value back to the database. Transaction B then reads the changed value. Before transaction A commits, however an error is detected and transaction A issues a rollback. The rollback could have been issued as a result of the user canceling the transaction or a result of failure. The value used by B is wrong. The

Figure: Example dirty read Problem

real SR value is now 10 because A changes was not permanent. An uncommitted dependency involves one transaction writing and another transaction reading the same part of the database.

3. Incorrect SummaryThe third problem, the incorrect summary is the least serious of the interference

problems. It occurs when a transaction calculating a summary function reads some values before another transaction changes the value but reads other values after another



Read SR(10) T1

SR = SR-1 T2

Write SR(9) T3

T4 Read SR(9)

Rollback T5

transaction changes the values. In figure, transaction B reads SR1 after transaction A changes the value but reads SR2 before transaction A changes the value. For consistency, transaction B should use all the values either before or after they are changed by another transaction. An incorrect summary involves one transaction reading and the second transaction changing the same part of the database.

Figure: Example Incorrect Summary Problem

Concurrency Control ToolsThis section describes two tools used by most DBMSs to prevent the three

interference problem discussed above. The tools are 1. Locks2. Two-Phase locking protocol

LocksLocks provide a way to prevent other users from accessing part of the database

being used. Before accessing part of the database, a lock must be obtained. Other users must wait if trying to obtain conflicting lock on the same part of the database. Following table shows conflicts for two kinds of locks.

User 2 RequestsS Lock X Lock

User 1 HoldsS Lock Lock Granted User 2 waitsX Lock User 2 waits User 2 waits

Table: Locking Conflicts



Read SR1(10) T1

SR1 = SR1-1 T2

Write SR1(9) T3

T4 Read SR1(9)

T5 Sum=Sum+SR1

T6 Read SR2(5)

T7 Sum=Sum+SR2

Read SR2(5) T8

SR2=SR2-1 T9

Write SR2(4) T10

A shared lock (S) must be obtained before reading the database, while an exclusive locks (X) must be obtained before writing. As shown in the above table, any number of users can hold a shared lock on the same part of the database whereas only one user can hold an exclusive lock.

The concurrency control manager is the part of the DBMS responsible for managing locks. The concurrency control manager maintains a hidden table to record locks held by various transactions. A lock record contains a transaction identifier, a record identifier, a kind, and a count, as explained in the following table

Field Name DescriptionTransaction Identifier Unique identifier for transactionRecord Identifier Identifies the record to be lockedKind Indicates the intended usage of the locked recordCount Number of other user holding this kind of lock

Table: Fields in a Lock RecordIn the simplest scheme, the kind is either shared or exclusive, as discussed

previously. Most DBMSs have other kinds of locks to improve efficiency and allow for more concurrent access. The concurrency control manager can perform two actions on lock records. The lock action adds a record to the lock table. Likewise, the unlock or release action deletes a record from the lock table.

Locking granularity is one complication about locks. Granularity refers to the size of the database item locked. The previous discussion assumed that locks are held for records. Most DBMSs can hold locks for different granularities, as depicted in the following figure.

Figure: Typical Levels of Locking Granularity

The entire database is the coarsest lock that can be held. If an exclusive lock is held on the entire database, no other users can access the database until the lock is released. On the other extreme, an individual field is the finest lock that can be held. Locks also can be held on parts of the database not generally seen by users. For example, locks can be held on indexes and pages (physical records).


Database

Table Index

Page

Record

Field

Locking granularity is a trade-off between overhead and waiting. Holding locks at a fine level decreases waiting among users but increases system overhead because more locks must be obtained. Holding locks at a coarser level reduces the number of locks but increases the amount of waiting. In some DBMSs, the concurrency control manages to detect the pattern of usage and promotes locks if needed. For example, the concurrency control manager initially can grant record locks to a transaction in anticipation that only a few records will be locked. If the transaction continues to request locks, the concurrency control component can promote the record locks to a lock on the entire table.

DeadlocksUsing locks to prevent interference problems can lead to deadlocks. A deadlock is

a problem of mutual waiting. One transaction has a resource that another transaction needs, and a second transaction holds a resource that the first transaction needs. Figure depicts a deadlock among two transactions trying to reserve seats on a flight involving more than one part.

Figure: Example deadlock Problem

Transaction A acquires an exclusive lock on the first part followed by transaction B acquiring a lock on the second part. Transaction A tries to lock the second part but is blocked because transaction B holds an exclusive lock. Likewise, transaction B must wait to obtain a lock on the first part. Deadlocks can involve more than two transactions. But the pattern is more complex. The concurrency control manager can either prevent deadlocks or detect deadlocks. To prevent deadlocks the concurrency control manager aborts transactions. Most DBMSs use a time out policy to select transactions to abort. The concurrency control manager aborts with a rollback statement any transaction waiting for more than a specified time. Some DBMS try to detect deadlock by looking for patterns of mutual waiting. Because detecting deadlocks can involve significant computation time, most DBMSs do not try to detect them.

Two phase Locking ProtocolTo ensure that lost update problems do not occur, the concurrency control

manager requires that all transactions follow the two-phase locking protocol (2PL). for concurrency control all the transaction must follow the 2PL protocol to ensure that no interference problems occur. Two-phase locking has two conditions:

1. Before reading or writing to a part of the database. The transaction must acquire the applicable lock to that part of database.



XLock SR1 T1

T2 XLock SR2

XLock SR2 (wait) T3

T4 XLock SR1 (wait)

SR(9) T5 Sum=Sum+SR1

2. After releasing a lock, the transaction doesn’t acquire any new locks.

The first condition follows from the usage of locks as explained previously. The second condition, if new locks are acquired after releasing locks, a group of transaction can operate on different states of a data item, leading to lost update problems. The second condition is usually simplified so that at least exclusive locks are held until the end of the transactions. At the commit points, locks of a transaction are released. The figure shows the 2PL with simplified second condition.

Figure: Growing and Shrinking Phases of 2PL

At the beginning of transaction (BOT), a transaction has no locks. A growing phase ensures in which transaction acquires locks but never release any locks. At the end of transaction (EOT), the shrinking phase in which all locks are released together. Simplifying the definition of 2PL makes the protocol easier to enforce and prevents other concurrency control problems.

Optimistic ApproachesThe use of locks and 2PL is a pessimistic approach to concurrency control.

Locking assumes that every transaction conflicts. Optimistic concurrency control approaches assumes that conflicts are rare. If conflicts are rare it is more efficient to check for conflicts rather than use of locks to force waiting. In this transactions are permitted to access the database without acquiring locks. Instead, the concurrency control manager checks whether a conflicts has occurred. The check can be performed either just before a transaction commits or after each read and write. If conflicts occur, the concurrency control manager issues a rollback and restarts the offending transaction. The performance of optimistic approaches depends on the frequency of the conflicts. If conflicts increase, the performance of optimistic approaches decreases. Optimistic approaches resolve conflicts by rollback and restarting.


Loc

ks H

eld

BOT EOTTime

Shrinking Phase

Growing Phase

Recovery ManagementRecovery management is a service to restore a database to a consistent state after

a failure. This section describes the kinds of failures to prevent, the tools of recovery management, and the recovery processes that use the tools.Data Storage Devices and Failure Types

From the perspective of database failures, volatility is an important characteristic of data storage devices. Main memory is volatile because it loses its state if power is lost. In contrast, a hard disk is nonvolatile because it retains its state if power is lost. This distinction is important because DBMSs cannot depend on volatile memory to recover data after failures. Even nonvolatile devices are not completely reliable. For example, certain failures make the contents of a hard disk unreadable. To achieve high reliability, DBMSs may replicate data on several kinds of nonvolatile storage media such as hard disk, magnetic tape, and an optical disk. Using a combination of non-volatile devices improves reliability because different kinds of devices usually have independent failure rates.

Some failures affect main memory only, while others affect both volatile and non-volatile memory. The following table shows four kinds of failures along with their effect and frequency. The first two kinds of failures affect memory of one executing transaction.

Type Effect FrequencyProgram-detected Local (1 transaction) Most frequentAbnormal termination Local (1 transaction) Moderate frequencySystem failure Global (all active transactions) Not frequentDevice failure Global (all active and past

transactions)Least frequent

Table: Failure Types, Effects, and Frequency

When writing code, one often checks for error conditions such as invalid account number or cancellation of the transaction by the user. A program-detected failure usually leads to aborting the transaction with the specified message to the user. The SQL ROLL BACK statement is used to abort a transaction if an abnormal condition occurs. Recall that the ROLL BACK statement causes all changes made by the transaction to be removed from the database. Program-detected failures are usually the most common and least harmful.

Abnormal termination has an effect similar to a program-detected failure but a different cause. The transaction aborts, but the error message is unintelligible to the user. Abnormal termination can be caused by events such as transaction time-out, communication line failure, or programming error (for example, dividing by zero). The last two kinds of failures have more serious consequences but are usually far less common. A system failure is an abnormal termination of the operating system. An operating system failure affects all executing transactions. A device failure such as a disk crash affects all executing transactions and all committed transactions whose work is recorded on the disk. A device failure can take hours to recover while a system crash can take minutes.


Recovery ToolsThe recovery manager uses redundancy and control of the timing of database

writes to restore a database after a failure. Three tools discussed in this section-transaction log, check point, and database backup-are forms of redundancy. The last tool-force writing-allows the recovery manager to control when database writes are recorded.

Transaction LogIt a like a shadow following a database. Any change to the database is also

recorded in the log. A typical log (following table) contains a transaction identifier, the database action, the time, a row identifier, a column name, and values (odd and new). The old and new values are sometimes called the before and after images, respectively. If the database action is insert, the log only contains the new value. Similarly, if the database action is delete, the log only contains the old value. Besides insert, update, and delete actions, log records are created for the begin and the end of the transaction. The log is usually stored as a hidden database table not available to normal users.

Trans No.

Action Time Table Row Column Old New

T101 BEGIN 10:29T101 Update 10:30 Acct A10 Bal 100 200T101 Update 10:30 Acct A25 Bal 500 400T101 Insert 10:32 Hist H100 CustNo C100T101 End 10:33

Table: Example Transaction log for an ATM Transaction

The recovery manager can perform two operations on the log. In an undo operation, the database reverts to a previous state by substituting the old value for whatever value is stored in the database. In a redo operation, the recovery component reestablishes a new state by substituting the new value for whatever value is stored in the database. To undo (redo) a transaction, the undo (redo) operation is applied to all log records of a specified transaction except for the begin and commit records.

Checkpoint TableThe checkpoint table is another hidden table used by the recovery manager. The

purpose of the checkpoint table is to reduce the time to recover from failures. At periodic times, a record is written to the checkpoint table to record the current log position. In addition, a checkpoint record is added to the log to record all active transactions and all log buffers are written to disk. At start time, the recovery manager consults the checkpoint table to commence the restoration process.

The checkpoint interval is defined as the period between writing to the checkpoint table. The interval can be expressed as a time (such as five minutes) or as a number of committed transactions. The checkpoint interval is a design parameter. A small interval reduces restart work but causes more overhead to record checkpoints. A large interval reduces checkpoint overhead but increases restart work. A typical checkpoint interval might be five minutes for large transaction volumes.


The implementation of the checkpoint process depends on the DBMS. In most DBMSs, all transaction activity must cease while a checkpoint occurs. Other systems permit concurrent transaction processing while a checkpoint occurs. The checkpoint interval should be larger (less frequent) if the DBMS requires all transaction activity to cease until a checkpoint completes.

Force WritingThe ability to control when data are transferred to nonvolatile storage is known as

force writing. Without the ability to control the timing of write operations to nonvolatile storage, recovery is not possible. Force writing means that the DBMS, not the operating system, controls when data are written to nonvolatile storage. Normally, when a program issues a write command, the operating system puts the data in a buffer. For efficiency, the data are not written to disk until the buffer is full. Typically, there is some small delay between the arrival of data in a buffer and the transferring of the buffer to disk. With force writing, the operating system allows the DBMS to transfer the data directly to disk without the intermediate use of the buffer.

The recovery manager uses force writing at checkpoint time and the end of the transaction. At checkpoint time, in addition to inserting a checkpoint record, all log and sometimes all database buffers are force written to disk. This force writing can add considerable overhead to the checkpoint process. At the end of the transaction, the recovery manager force writes any log records of a transaction remaining in memory.

Database BackupA backup is a copy of all or part of a disk. The backup is used when the disk

containing the database or log is damaged. A backup is usually made on a magnetic tape because it is less expensive and more reliable than disk. Periodically, a backup should be made for both the database and the log. To save time, most backup schedules include less frequent massive backups to copy the entire contents of a disk and more frequent incremental backups to copy only the changed part.

Recovery ProcessesThe recovery process depends on the kind of failure. Recovery from a device

failure is simple but can be time consuming, as listed below: The database is restored from the most recent backup. Then, the recovery manager applies the redo operator to all committed

transactions after the backup. Because the backup may be several hours to days old, the log must be consulted to restore transactions committed after the backup.

The recovery process finishes by restarting incomplete transactions.For local failures and system failures, the recovery process depends on when database changes are recorded on disk. Database changes can be recorded before the commit (immediate update) or after the commit (deferred update). The amount of work and the use of log operations (undo and redo) depend on the timing of database updates. The remainder of this section describes recovery processes for local and system failures under each scenario.


Immediate UpdateIn the immediate update approach, database updates are written to the disk when

they occur. Database writes occur at checkpoint time and when buffers are full. However, it is essential that database writes occur after writes of the corresponding log records. This usage of the log is known as the write ahead log protocol. If log records were written after corresponding database records, recovery would not be possible if a failure occurred between the time of writing the database records and the log records.

Recovery from a local failure is easy because only a single transaction is affected. All log records of the transaction are found. The undo operation is then applied to each log record of the transaction. If a failure occurs during the recovery process, the undo operation is applied again. The effect of applying the undo operator multiple times is the same as applying undo one time. After completing the undo operations, the recovery manager may offer the user the chance to restart the aborted transaction.

Recovery from a system failure is more difficult because all active users are affected. To help you understand recovery from a system failure, the figure shows the progress of a number of transactions with respect to the end of a transaction, most recent checkpoint, and the failure.

Each transaction represents a class of transactions. For example, transaction class T1 represents transactions started and finished before the checkpoint (and the failure). There are no other kinds of transactions possible.

The immediate update approach may involve both undo and redo operations, as summarized in the following table.

Class Description Restart WorkT1 Finished before CP NoneT2 Started before CP; finished before failure Redo forward from checkpoint


Checkpoint Failure

Time

T1

T2

T3

T5

T4

Figure: Transaction Time line

T3 Started after CP; finished before failure Redo forward from checkpointT4 Started before CP; not yet finished Undo backwards from most recent

log recordT5 Started after CP, not yet finished Undo backwards from most recent

log record Table: Summary of restart work for the immediate update approach

To understand the amount of work necessary, remember that log records are stable at checkpoint time and end of transaction and database changes are stable at checkpoint time. Although other database writes occur when a buffer fills, the timing of other writes is unpredictable. T1 transactions require no work because both log and database changes are stable before the failure. T2 transactions must be redone from the checkpoint because only database changes prior to the checkpoint are stable. T3 transactions must be redone entirely because database changes are not guaranteed to be stable even though some changes may be recorded on disk. T4 and T5 transactions must be undo entirely because some database changes after the checkpoint may be recorded on disk.

After a system failure, the checkpoint table and the log are used to restore transactions to a consistent state. Using the most recent checkpoint record, the recovery manager locates the log record written at the time of the checkpoint. Active transactions are classified, as specified in the above table. The recovery manager applies the undo operator to all T4 and T5 transactions and the redo operator to all T2 and T3 transactions. Finally, all T4 and T5 transactions are restarted.

Deferred UpdateIn the deferred update approach, database updates are written to disk only after a

transaction commits. No database writes occur at checkpoint time except for already committed transactions. The advantage of the deferred update approach is that undo operations are not necessary. However, it may be necessary to perform more redo operations than in the immediate update approach.

Local failures are handled without any restart work in the deferred update approach. Because no database changes occur until after a transaction commits, the transaction is aborted without any undo work. The recovery manager may still provide the user with the option of restarting the transaction.

System failures can be handled without undo operations as depicted in the following table.

Class Description Restart WorkT1 Finished before CP NoneT2 Started before CP; finished before failure Redo forward from first log recordT3 Started after CP; finished before failure Redo forward from first log recordT4 Started before CP; not yet finished NoneT5 Started after CP, not yet finished None

Table: Summary of restart work for the deferred update approach


T4 and T5 transactions (not yet committed) do not require undo operations because no database changes are written to disk until after a transaction commits. T2 and T3 transactions (committed after the checkpoint) require redo operations because it is not known whether all database changes are stable. T2 transactions (started before the checkpoint) must be redone from their first log record rather than just from the checkpoint as in the immediate approach. Thus, the deferred approach requires more restart work for T2 transactions than does the immediate update approach. However, the deferred update approach requires no restart work for T4 and T5 transactions, while the immediate update approach must undo T4 and T5 transactions.

TP MonitorShort for Transaction Processing monitor, a program that monitors a transaction

as it passes from one stage in a process to another. The TP monitor's purpose is to ensure that the transaction processes completely or, if an error occurs, to take appropriate actions. TP monitors are especially important in three-tier architectures that employ load balancing because a transaction may be forwarded to any of several servers. In fact, many TP monitors handle the entire load balancing operations, forwarding transactions to different servers based on their availability.

Purpose and OriginTransaction processing (TP) monitor technology provides the distributed

client/server environment the capacity to efficiently and reliably develop, run, and manage transaction applications.

TP monitor technology controls transaction applications and performs business logic/rules computations and database updates. TP monitor technology emerged 25 years ago when Atlantic Power and Light created an online support environment to share concurrently applications services and information resources with the batch and time-sharing operating systems environment. TP monitor technology is used in data management, network access, security systems, delivery order processing, airline reservations, and customer service. Use of TP monitor technology is a cost-effective alternative to upgrading database management systems or platform resources to provide this same functionality. TP monitor technology is software that is also referred to as Middleware. It can provide application services to thousands of clients in a distributed client/server environment. TP monitor technology does this by multiplexing client transaction requests (by type) onto a controlled number of processing routines that support particular services. These events are depicted in Figure.


Figure: Transaction Processing Monitor Technology

Clients are bound, serviced, and released using stateless servers that minimize overhead. The database sees only the controlled set of processing routines as clients. TP monitor technology maps numerous client requests through application services routines to improve system performance. The TP monitor technology (located as a server) can also take the application transitions logic from the client. This reduces the number of upgrades required by these client platforms. In addition, TP monitor technology includes numerous management features, such as restarting failed processes, dynamic load balancing, and enforcing consistency of distributed data. It is easily scalable by adding more servers to meet growing numbers of users.

It is independent of the database architecture. It supports flexible and robust business modeling and encourages modular, reusable procedures. TP monitor designs allow Application Programming Interfaces (APIs) to support components such as heterogeneous client libraries, databases and resource managers, and peer-level application systems. It supports architecture flexibility because each component in a distributed system is comprised of products that are designed to meet specific functionality, such as graphical user interface builders and database engines.

Usage Considerations

Within distributed client/server systems, each client that is supported adds overhead to system resources (such as memory). Responsiveness is improved and system resource overhead is reduced by using this technology to multiplex many clients onto a much smaller set of application service routines. This technology provides a highly active system that includes services for delivery order processing, terminal and forms management, data management, network access, authorization, and security. TP monitor technology supports a number of program-to-program communication models, such as store-and-forward, asynchronous, Remote Procedure Call (RPC), and conversational.


This improves interactions among application components. It provides the ability to construct complex business applications from modular, well-defined functional components. Because this technology is well known and well defined it should reduce program risk and associated costs. A limitation to TP technology is that the implementation code is usually written in a lower-level language (such as COBOL), and is not yet widely available in the popular visual tool sets.

A variation of TP monitor technology is session-based technology. In the TP monitor technology, transactions from the client are treated as messages. In the session based technology, a single server provides both database and transaction services. In session based technology, the server must be aware of clients in advance to maintain each client's processing thread. The session server must constantly send messages to the client (even when work is not being done in the client) to ensure that the client is still alive. Session based architectures are not as scalable because of the adverse effect on network performance as the number of clients grow.

Another alternative to TP monitor technology is remote data access (RDA). The RDA centers the application in a client computer, communicating with back-end database servers. Clients can be network-intensive, but scalability is limited.

A third alternative to TP monitor technology is the database server approach, which provides functions (usually specific to the database) and is architecturally locked to the specific database system.


Transaction Processing and Con Currency Control

Documents

Transcript of Transaction Processing and Con Currency Control