Transaction Processing

The execution of business operations consisting of one or several requests or updates to a system as discrete units of work, each of them a transaction.

A transaction has a start and it is finished by either a commit-command to activate all its changes made to the system or by a rollback-command to roll back the system to the previous state

That means: A transaction either processes all of its changes or none of them. After the execution the system is always left in a valid state.

Transactions have 4 basic properties - the so called ACID properties

A = Atomicity (a transaction is completely finished or completely rolled back)
C = Consistency (system gets a valid new state or stays in the previous state)
I = Isolation (transaction is separated from other ones during processing)
D = Durability (system is left in a valid state even after a system failure)

See AtomicConsistentIsolatedDurable

-- AndreasFrohnhaus

I've always thought of deadlock resolution as a "de-facto" requirement of any general transaction system too, but I've heard rumours that a lot of popular database systems don't do this. I'm still trying not to believe what I've heard about mysql not even handling ACID, I've built things with it assuming that it did! -- LukeGorrie

One technique for achieving ACID transactions without the possibility of deadlocks is MultiversionTimeStampOrdering? How does this differ from OptimisticLocking?

Also the title of a standard book on the subject by JimGray and AndreasReuter?. (TransactionProcessingConceptsAndTechniques)

This description talks in terms of a single system. Have to also consider a DistributedTransaction where multiple systems can be involved. -- BernardFarrell

EditHint: There seems to be central page about TransactionProcessing.

See AtomicConsistentIsolatedDurable

CategoryTransactionProcessing