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 also TransactionScript, TransactionProcessingMonitor, TransactionDesign, TransactionalDatabase and TransactionalFileSystem. See AtomicConsistentIsolatedDurable ---- CategoryTransactionProcessing