ACID transaction within a centralized database system.Edit
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 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.
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 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.
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)Edit
- Which problems does this solve?
- Difference from ACID?
Må finne mer info.
- When user interaction is needed
- Autonomous systems are involved
- Time consuming actions are executed
- 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 MultidatabasesEdit
Look at articlefor Multidatabases for more specific information.
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.
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.
This arises due to some sites that may not reveal their prepeare-to-commit state and not participate in a global commit protocol.
Can construct scenarios in where occurance of deadlock is possible
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
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 TransactionsEdit
Transaction within a data warehouseEdit
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 environmentEdit
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 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)Edit
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:
- 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
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)Edit
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
- 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)
How many cases of tomatoes were sold in all storehouses in the years 2007 and 2008?
Look at article for Data Warehouse.