Transaction

ACID transaction within a centralized database system.
ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties which guarantees that a transaction is processed correctly. In the context of a centralized database, the transaction itself is a simple logical operation which affects data. An example for such a transaction is to transfer money from one bank account to another. Even though it consists of several smaller operations, the transfer is still considered as one singular transaction.

Transaction which fulfill the ACID properties are often referred to as atomic transactions.

Atomicity
Atomicity refers to the DBMS ability to guarantee that either all operations are preformed or none at all. In the bank account example, this property guarantees that the first account won’t be credited without the other being debited, and vica versa.

Consistency
The consistency-property guarantees that the database resides in a constant state both before and after the execution of the transaction, regardless of whether it was carried out properly or not. This means that if a transaction which breaks the consistency property is executed, the whole transaction is rolled back, and the database is reset to a state which satisfies the consistency property.

Isolation
Isolation refers to the requirement that other operations can’t whether access or view data which is in an intermediate stage during a transaction. This restriction is necessary to maintain performance and consistency between transactions in a DBMS. No transactions are aware of any other transactions which are executed at any given time.

Durability
As soon as the user is made aware of the success of a transaction, the transaction will not at any circumstance be changed or cancelled. If the DBMS guarantees this, it is considered durable. This basically means that a transaction would even survive a system crash. To achieve this property, a common technique which is practiced is keeping track of a system log.

Transaction model for long lasting transactions (extended/advanced transaction models)

 * Which problems does this solve?
 * Difference from ACID?

Må finne mer info.

When needed:


 * When user interaction is needed


 * Autonomous systems are involved


 * Time consuming actions are executed

Requires:


 * Non-ACID transactional requirements


 * Non-traditional transaction processing


 * Nested transaction execution


 * Reveal of partial results -> unilateral commit


 * May use alternative sub-transaction executions

Transactions within Multidatabases
Look at articlefor Multidatabases for more specific information.

Transaction Processing


Traditional properties (ACID) and structure is genereally not suitable, due to reasons such as autonomy, heterogeneity, long duration of transactions, etc. Global transactions in such a system is decomposed into a number of sub-transactions, which follows the nested transaction model.

Transaction Management
Both the global and the local DBMS have seperate transaction managers.This leads to a seperation of control, where local transactions are executed by each local DBMS outside of the multidatabase system control, while global transactions are executed under the multidatabase control.

Global Atomicity
This arises due to some sites that may not reveal their prepeare-to-commit state and not participate in a global commit protocol.

Global Deadlock
Can construct scenarios in where occurance of deadlock is possible

Example:

Assume Local Database 1 (LDB1) and Local Database 2 (LDB2) use 2 phase locking. If a deadlock is formed of both global and local transactions, then:
 * Global Transaction Manager will not know of it
 * LDBs will not share control information

Global Serializability
Transactions throughout the MDBS are serializable, i.e. the transactions are equivalent to some serial execution. The Global Transaction Manager can only ensure that the global transactions are serializable, while the Local Transaction Managers only can ensure that local transactions at a specific site are serializable. This does not guarantee global serializability due to indirect conflicts.

Nested and Multilevel Transactions
There are basically 3 types of nested/multilevel transaction:

Multilevel Transactions:

Subtransaction of T is permitted to release locks on completion.

Saga

Multilevel long-duration transaction.

Nested Transaction

Locks held by a subtransaction ti of T are automatically assign to T on completion of ti.

A nested or multilevel transaction T is represented by a set T = {T1,T2,...,Tn} subtransactions and a partial order P on T. Each subtransaction Ti in T may abort without forcing T to abort, but instead, T could choose to restart the subtransaction, or simply choose not to run it. If Ti commits, it is not automatically done permanent as it basically commits back to T, which may still abort (or require compensation). When T has commited, all subtransactions should be permanent. Subtransactions can themselves be nested/multilevel transactions, and the lowest level of nesting is standard read/write operations.

Sagas
Sagas are referred to as "A sequence of (flat) transactions that can be interleaved with other transactions".

DBMS guarantees that either all transactions in saga are successfully completed, or compensating transactions are run to undo partial execution. Sagas has only one level of nesting, and for every sub transaction defined, there is corresponding compensating transactions which will semantically undo the sub transactions effect.

The property of isolation is relaxed, as the saga is allowed to reveal its partial results to other concurrently executing transactions before it completes. This is useful when sub transactions are relatively independent and compensating transactions can be produced. All though, it is sometimes difficult to define compensating transactions in advance, so the DBMS may need to interact with the user to determine compensation.

Transaction within a data warehouse
Transaction within a data warehouse works similar to transactions within a centralized database. All though, data found in the warehouse might not be fully up to date, as newly updated data might not have been pushed/pulled from the local databases. ???

Explain the difference between transaction processing for multi-database systems and data warehouse.

Transactions within a mobile environment
When making transactions within a mobile environment, devices could encounter being outside of service. This basically leads to making the database somehow inconsistent, as not all data is guaranteed to be up to date,

Compensating Transactions
Compensating is an alternative to the "undo" operations when transactions fail. Basically, what it does is instead of undoing or rolling back changes which have been done, actions are taken to compensating for the failure. This is done by performing operations which are “inverted” to the original operation which were run when the system failed. A practical example would be when transferring money from one account to another where the transaction fails after the money from the first account has been withdrawn, but before it has be deposited into the second account. The undo operation would normally just cancel the withdrawing, while using compensation the money would actually be deposited back into the first account instead of any operation being cancelled.

On Line Transaction Processing (OLTP)
Maintains a database that is an accurate model of some real-world enterprise, which supports day-to-day operations. Used in standard databases.

Charateristics for OLTP: Purpose:
 * Short simple transactions
 * Relative frequent updates
 * Transactions access only a small fraction of the database
 * Mostly updates
 * Many small transactions
 * Current snapshot
 * Index on p.k.
 * Raw data
 * Thousands of users
 * Up-to-date data
 * Consistency, recoverability critical

Example:

John Smith just bought a box of tomatoes -> charge his account -> deliver the tomatoes from our Coop storehouse -> decrease our inventory of tomatoes from that storehouse

On Line Analytic Processing (OLAP)
Uses information in database to guide strategic decisions. Used in data warehouses.

Characteristics of OLAP:


 * Complex queries


 * Infrequent updates


 * Transactions access a large fraction of the database

Purpose:
 * Data need not to be "up-to-date"
 * Mostly updates
 * Queries are long and complex
 * Generally huge amounts of data
 * Historical data
 * Summarized consol. data
 * Hundreds of users (e.g., decision-makers, analysts)

Example:

How many cases of tomatoes were sold in all storehouses in the years 2007 and 2008?

Aggregation
Look at article for Data Warehouse.