The purpose of this report is to examine the idea of transaction management and how it relates to two different database systems that I have chosen for the purpose of the project and for may research. I am also looking at the different elements with regard to transaction management and how each of them work and what they are for in the overall scheme that is transaction management.
I will go through the definition of transaction the meaning of transaction how it functions the limitations and restrictions on the access to the user. I delve into the four properties of transactions Atomicity consistency isolation and durability.
We discuss the transaction states and go through all six states partially committed failed rollback aborted committed and terminated.
I will also cover things concurrent execution and serizabilty and then I will detail a brief history of the two databases I have chosen then do an analysis of how Concurrency and Recovery has being implemented by both of these Databases with conclusion at the end with bibliography
A transaction is an event that happens within a database and general it enters values or exports them from a database. When we look at a transaction from the point of an operating system than transaction is analogous to processes.
All though there are two classes in a transaction of entering and reading data there are differences between them. When the user reads the information they cannot change the information nor alter it in anyway. But it is a different case when you are entering the information then the exact opposite you alter any table or data.
The Four Properties of Transactions
The four properties of transaction are acid that is atomicity consistency isolation and durability every transaction for whatever purpose it is being used has these properties
It means that in any transaction that happens in a database there are two outcomes one being that all the instructions about what tasks have to be complete for the transaction to fully go through are taken and done. Then within the transaction every step to completion is recorded and stored within the database. The second choice is that something happens anything it doesn’t matter but what does matter is that the transaction doesn’t go through and the transaction terminates the operation completely without any backup or storing of information.
That is the basis of atomicity it is either or it either completes the transaction and stores the relevant data or it doesn’t and dumps everything in favour of starting a new transaction.
An example of this as I read it from an online source is “in an online airline-booking system, a booking may consist of 2 separate actions that together form a transaction -- paying for the seat, and reserving the seat for the customer who’s just paid. Business logic dictates that these two, though distinct and separate actions, must occur together. If one happens without...