You are on page 1of 3

Concurrency control in Real Time Databases

HARMEET KAUR (01) M.TECH (C.S.E part time) e-mail:-harmeetpunjaban@gmail.com

Abstract : A real time database is a database system where transactions have explicit timing constraints such as deadlines. Concurrency control is one of the main issues in the study of real time database systems. In addition to satisfying consistency requirements as in traditional database systems, a real time transaction processing system must also satisfy timing constraints. Concurrency means that different users have access to the database at the same time. In such asystem each user must be protected against others. We must avoid the situation in which one user is altering an object in the database, while another user is reading it. The task of a concurrency control mechanism is to ensure the consistency of the database while allowing a set of transactions (i.e., users programs) to execute concurrently.To support real time transaction processing the new criteria and issues to be considered in design and implementation of real time database systems are scheduling of CPU and I/O and the requirement that conflict resolution schemes used should be time cognizant. Introduction Concurrency control in Real time databases is more complex than in traditional DBS. Apart from ensuring database consistency also transaction timing constraints should be guaranteed. Moreover, validity and values of data items change in time. Concurrency control algorithms for real time databases are in general some extensions or combinations of traditional concurrency control techniques, i.e. two phase locking (2PL), optimistic concurrency control (OCC) or timestamp ordering (TO), which guarantee a serialization order among conflicting transactions. Each database transaction usually involves accesses to several data items, using which it carries out the necessary processing. Each access to data items takes considerable time especially if disk accesses are involved. This contributes to making Transactions to be of longer duration than a typical task execution in a non-database application. For improved

throughput, it is a good idea to start the execution of a transaction as soon as the transaction becomes ready (that is, concurrently along with other transactions already under execution), rather than executing them one after the other. Concurrent transactions at any time are those which are active (i.e. started but not yet complete). The concurrent transactions can operate either in an interleaved or in a "truly concurrent"mannerit does not really matter. What is important for a set of transactions to be concurrent is that they are active at the same time It is very unlikely to find a commercial database that does not execute its transactions concurrently. However, unless the concurrent transactions are properly controlled, they may produce incorrect results by violating some ACID properties, e.g. result recorded by one transaction is immediately overwritten by another. The main idea behind concurrency control is to ensure non-interference (isolation and atomicity) among different transactions. concurrency control protocols usually adopt any of the following two types of approaches. concurrency control can be achieved either by disallowing certain types of transactions from progressing, or by allowing all transactions to progress without any restrictions imposed on them, and then pruning some of the transactions. These two types of concurrency control protocols correspond to pessimistic and optimistic protocols. In a pessimistic protocol, permission must be obtained by a transaction, before it performs any operation on a database object. Permissions to transactions to access data items is restricted normally through the use of some locking scheme. O ptimistic schemes neglect such permission controls and allow the transactions to freely access any data item they require. However, at transaction commitment, a validation test is conducted to verify that all database accesses maintain serializability. In the following, we first discuss a traditional lockingbased concurrency control protocol called 2PL that is being popularly used in commercial non-real time

database management systems. We then discuss how this protocol has been extended for real-time applications. Subsequently, we examine a few optimistic concurrency control protocols designed for real-time applications Locking-based Concurrency control 2PL :- It is a pessimistic protocol that restricts the degree of concurrency in a database. In this scheme, the execution of a transaction consists of two phases :a growing phase and a shrinking phase. In the growing phase, locks are acquired by a transaction on the desired data items. Locks are released in the shrinking phase. Once a lock is released by a transaction, its shrinking phase starts, and no further locks can be acquired by the transaction. In 2PL-HP a conict is resolved in favor of the higher priority transactions. When a conflict occurs, if the requesting transaction has a higher priority than all the lock holders the lock holders are aborted and the requester gets the lock. Otherwise it waits for the holder to release the lock. Thus the 2PL-HP is in essence similar to the wound wait scheme .However the two schemes differ in their priority assignment. In the wound_wait scheme priorities are based on the arrival times instead of the deadlines since the objective is fairness so every transaction will eventually receive a high enough priority to get through. Priority Ceiling Protocol: Let us now discuss Priority Ceiling Protocol ( PC P) for databases .Unlike PCP for resource sharing among tasks ;PC Pin database concurrency control does not make use of any priority inheritance. The main concept involved in this protocol is the establishment of a total priority ordering among all transactions. This protocol associates the following three values with every data object. ReadCeil in g :This value indicates the priority value of the highest priority transaction that may write to the data object. Absolute Ceiling :This is the highest priority transaction that may read or write the data object. Read-Write Ceiling :This value is defined dynamically at run time. When a transaction writes to a data object, the read-write ceiling is set equal to the absolute ceiling. However, read-write ceiling is set equal to the read ceiling for a read operation. Optimistic Concurrency Control Protocols The basic idea of an Optimistic Concurrency Control Protocols mechanism is that the execution of a

transaction consists of three phases: read, validation and write phases as in Fig. 1. For Optimistic Concurrency Control Protocols (OCC) schemes a conflict is detected after the data object has been accessed. In the OCC, conflict detection and resolution are both done at the certification time when a transaction completes its execution; it requests the Concurrency Control Protocols manager to validate all its accessed data objects. If it has not yet been marked for abort, it enters the commit phase where it writes all its updates to the database. Backward-oriented OCC (BOCC) checks during the validation test of Tj whether its readset RS(Tj) intersects with any of the write sets WS(Ti) of all concurrently executed transactions Ti having finished their read phases before Tj. Forward-oriented OCC (FOCC) checks during the validation phase of Tj whether its write set WS(Tj) intersects with any of the read set RS(Ti) of all transactions Ti having not yet finished their read phases

Figure1:- three phases of optimistic concurrency control Extension of Optimistic Concurrency Control Protocols for RTDBS: Ideally Optimistic Concurrency Control Protocols (OCC) should be non-blocking and deadlock free. These properties make OCC attractive in real-time transaction processing. OCC may be in a better position to be integrated with priority driven CPU scheduling. To adapt OCC into RTDBS the main issue is how to incorporate priorities (time constraints) into conflict resolution. The key component of Optimistic Concurrency Control Protocols schemes is the validation phase where a transaction's destiny is decided. Transaction validation can be performed in one of two ways: forward validation and backward validation. In protocols that perform backward validation the validating transaction either commits or aborts depending on whether it has conflicts with transactions that have already committed. So this scheme does not allow us to take transaction characteristics into account and it is not suitable for real-time database. In forward validation however, either the validating transaction or the conflicting ongoing transactions can be aborted to resolve conflicts. This scheme can be extended to realtime database since the timing characteristics of

transaction can be considered and proper decision can be taken in aborting, delaying the committing transaction or aborting the conflicting ongoing transactions. Here explain below the three schemes OCC-forward validation: In this scheme (OCC_FV) the transaction that reaches its validation phase is allowed to commit if it is not a virtual first run transaction and all the active conflicting transactions which are in their read phases are immediately aborted and restarted if they are rerun transactions. In case some of the conflicting read phase transactions are in their first run, instead of aborting them they enter their virtual run and continue their read phase so as to bring data objects required to buffer, assuming the system buffer has a high retention effect, then a transaction in its second run and onward does not need to access the disk since the data objects are already in memory. When the virtual run transaction completes its read phase, it is aborted and resubmitted to the system to start its real second run. It is clear that there is no point to allow restarted rerun transaction tocomplete its read phase in virtual mode since all its data items are already in memory. This scheme does not take the transactions timing constraints into account and favours the validating one to save the amount of progress done by the validating transaction since it is near completion and will definitely complete if it is not restarted. OCC-sacrifice: It is an optimistic protocol which uses a priority-driven abort for conflict resolution. In this protocol (OCC_OS) when a transaction reaches its validation phase, it is aborted if one or more conflicting transactions have higher priority than the validating one; otherwise it commits and all the conflicting read phase transactions are restarted immediately. This protocol uses transaction priority (timing constraints) in such a way that the validating transaction sacrifices itself for the sake of conflicting ones with higher priority. If some of the restarted read phase transactions are in its first run, it enters the virtual run phase as explained above to complete its read phase, so its access pattern will be known and brought to buffer. On completing its virtual run, it is aborted and restarts its real second run Conclusions Concurrency control is one of the main issues in the studies of real-time database systems. In this paper different distributed concurrency control methods are studied in a real-time system environment.

Concurrency control algorithms for real time databases are in general some extensions or combinations of traditional concurrency control techniques, i.e. two phase locking (2PL), optimistic concurrency control (OCC) or timestamp ordering (TO), which guarantee a serialization order among conflicting transactions References [1] Ozsoyoglu, G. and R. Snodgrass, 1995. Temporal and real-time databases. IEEE Trans. On Knowledge and Data Engg., 7: 513-532. [2] Lee, J., and Son, S.H., "Performance of Concurrency Control Algorithms for Real-Time Database Systems", Kumar V. (ed.) Performance of Concurrency Control Mechanisms in Centralized Database Systems, Prentice Hall, 1995. [3] zsoyoglu, G., and Sondgrass, R.T., "Temporal and Real-Time Databases: A Survey",IEEE Transactions on Knowledge and Data Engineering, Vol. 7, no. 4, 1995. pp. 513-532. [4] Ramamritham, K., "Real-Time Databases", Distributed and Parallel Databases Vol. 1, no. 2, 1993, pp. 199-226. [5] Haritsa, J.R., Carey, M.J., and Livny, M., "Data Access Scheduling in Firm Real-Time Database Systems", The Journal of Real-Time Systems, no. 4, 1992, pp. 203-241. [6] Bernstain, P.A., Hadzilacos, V., and Goodman, N., "Concurrency Control and Recovery in Database Systems", Reading, MA: Addison Wesley, 1987.