Transaction management:

The transaction management system is accountable for scheduling system activity managing physical resources and managing system shutdown and restart. It comprises components that perform recovery, scheduling, logging and locking.

Generally transaction management performs those operating system functions not available from the basic operating system. It does this either by extending the OS objects (example Enhancing processes to have recovery and logging) or by providing completely new facilities (example independent recovery management.) As these functions grow to be better understood the duties of transaction management will slowly migrate into the operating system.

Transaction organization implements the following objects:

Transaction descriptor- A transaction descriptor is the prototype for a transaction giving instructions on how to build an instance of the transaction. The descriptor explains how to schedule the transaction what recovery and locking options to use what data base views the transaction needs what program the transaction runs and how much space and time it requires.

Process- A process (domain) that is able of running or is running a transaction. A process is bound to a program as well as to other resources. A process is a unit of scheduling as well as resource allocation. Over time a process may perhaps execute several transaction instances although at any instant a process is executing on behalf of at most one transaction instance. Equally a transaction instance may involve several processes. Multiple simultaneous processes executing on behalf of a single transaction instance are called cohorts. Data management system procedures are fancier than operating system processes since they understand recovery, locking and logging protocols however we will continue to use the old (familiar name for them).

Transaction instance: A process or else collection of processes (cohorts) executing a transaction. A transaction instance is a unit of locking as well as recovery.

In what follows we shall blur these distinctions as well as generically call each of these objects transactions unless a more precise term is needed.

The life of a transaction instance is quite simple - A message or else request arrives which causes a process to be built from the transaction descriptor. The process subject a BEGIN_TRANSACTION action that establishes a recovery unit. It afterwards issues a series of actions against the system state. Ultimately it issues the COMMIT_TRANSACTION action that causes the outputs of the transaction to be made public (both updates and output messages.) On the other hand if the transaction runs into trouble it may issue the ABORT TRANSACTION action which cancels all actions performed by this transaction.

The system offers a set of objects as well as actions on these objects along with a set of primitives that permit groups of actions to be collected into atomic transactions. It assurances no consistency on the objects beyond the atomicity of the actions. That is an action wills either effectively complete or it will not modify the system state at all.

Additionally if two actions are performed on an object then the result will be equivalent to the serial execution of the two actions. (As explained below this is accomplished by using locking within system actions.)

The notion of transaction is introduced to offer a similar abstraction above the system interface. Transactions are an every or nothing thing either they happen completely or all trace of then (except in the log) is erased.

Before a transaction completes it perhaps aborted and its updates to recoverable data may be undone.

The abort is able to cone either from the transaction itself (suicide- operator cancel, bad input data,….) or from outside (murder- timeout, deadlock, system crash.... ) nevertheless once a transaction commits (effectively completes) the effects of the transaction can’t be blindly undone. Rather to undo a committed transaction one should resort to compensation - running a new transaction that corrects the errors of its predecessor. Compensation is typically highly application dependent and isn’t provided by the system.

These definitions perhaps clarified by a few examples. The subsequent is a picture of the three possible destinies of a transaction.

A easy transaction takes in a single message does something, and then produces a single message.

Easy transactions typically make fifteen data base calls. Almost every transaction is simple at present (see Guide/Share Profile of IMS users). About half of all easy transactions are read-only (make no changes to the database.) For easy transactions the notion of process, recovery unit and message coincide.

If a transaction sends as well as receives several synchronous messages it is called a conversational transaction. A conversational transaction has numerous messages per process and transaction instances.

Conversational transactions are probable to last for a long time (minutes while the operator thinks and types) and hence pose special resource management problems.

The term batch transaction is utilized to describe a transaction that is ‘unusually big’. Generally such transactions are not on-line rather they are typically started by a system event (timer driven) and run for a long time as a ‘background’ job. Such a transaction typically performs thousands of data management calls prior to terminating. Habitually the process will commit some of its work before the entire operation is complete. This is an illustration of multiple (related) recovery units per process.

If a transaction does work at numerous nodes of a network then it will require a process structure (cohort) to represent its work at every participating node. Such a transaction is specified as distributed.

The following table reviewed the possibilities and shows the independence of the notions of process message and transaction instance (commit). Cohorts communicate with one more via the session message facilities provided by data communications.

We introduce a supplementary notion of save point in the notion of transaction. A save point is a firewall that permits a transaction to stop short of total backup. If a transaction gets into trouble (example deadlock, resource limit) it may be enough to back up to such an intermediate save point rather than undoing all the work of the transaction. For instance a conversational transaction which involves several user interactions might establish a save point at every user message thereby minimizing retyping by the user.

Save points don’t commit any of the transaction's updates. Every save point is numbered the beginning of the transaction is save point 1 and successive save points are numbered 2, 3. . . . . The user is authorized to save some data at each save point and to retrieve this data if he returns to that point. Backing up to save point 1 rearrange the transaction instance to the recovery component provides the actions:

BEGIN_TRANSACTION designates the beginning of a transaction.
SAVE_TRANSACTION designates a firewall within the transaction.

If an unfinished transaction is backed-up undo may perhaps stop at such a point rather than undoing the entire transaction,

BACKUP_TRANSACTION: undoes the consequences of a transaction to an earlier save point.
COMMIT_TRANSACTION: signals victorious completion of transaction and causes outputs to be committed.
ABORT_TRANSACTION: causes loosen of a transaction to its initial state.

Using these primitives’ application programs is able to construct groups of actions that are atomic. It is attractive that this one level of recovery is sufficient to support multiple levels of transactions by using the notion of save point.

The recovery component supports two actions that transaction with system recovery rather than transaction recovery:

CHECKPOINT: Coordinates the copy of the system state in the log.
RESTART: Coordinates system resume reading the checkpoint log record and using the log to redo committed transactions and to undo transactions that were uncommitted at the time of the shutdown or crash.

Latest technology based Operating System Online Tutoring Assistance

Tutors, at the www.tutorsglobe.com, take pledge to provide full satisfaction and assurance in Operating System help via online tutoring. Students are getting 100% satisfaction by online tutors across the globe. Here you can get homework help for Operating System, project ideas and tutorials. We provide email based Operating System help. You can join us to ask queries 24x7 with live, experienced and qualified online tutors specialized in Operating System. Through Online Tutoring, you would be able to complete your homework or assignments at your home. Tutors at the TutorsGlobe are committed to provide the best quality online tutoring assistance for Operating System Homework help and assignment help services. They use their experience, as they have solved thousands of the Operating System assignments, which may help you to solve your complex issues of Operating System. TutorsGlobe assure for the best quality compliance to your homework. Compromise with quality is not in our dictionary. If we feel that we are not able to provide the homework help as per the deadline or given instruction by the student, we refund the money of the student without any delay.