A transaction symbolizes a unit of work performed within a database management system (or similar system) against a database, and treated in a coherent and reliable way independent of other transactions. A transaction generally represents any change in a database. Transactions in a database environment have two main purposes:
In Database Management system, A Transaction is a single unit of many logical operations/work. In simple words, Any logical calculations done in a consistent mode in Database is known as Transaction. Best one example is, ATM that we use on regular basis.
Transactions provide an "all-or-nothing" proposition, stating that each work-unit performed in a database must either complete in its entirety or have no effect whatsoever. Further, the system must isolate each transaction from other transactions, results must conform to existing constraints in the database, and transactions that complete successfully must get written to durable storage.
Let us understand with this table :-
|Person A with Having 300 Rs
and have supposed to receive 100 Rs from Person B
|Person B with having 200 Rs and wants to transfer 100 Rs to Person A|
|R(A);// Reading the data of A||R(B); // Reading the data of B|
|A= A+ 100; // Plus in total of A||B= B-100; // Minus in total of B|
|W(A); //Writing the data of A||W(B); //Writing the data of B|
|R(A) ; // Output comes as 400 Rs||R(B); // Output comes as 100 Rs.|
Databases and other data stores which treat the integrity of data as paramount often include the ability to handle transactions to maintain the integrity of data. A single transaction consists of one or more independent units of work, each reading and/or writing information to a database or other data store. When this happens it is often important to ensure that all such processing leaves the database or data store in a consistent state.
Examples from double-entry accounting systems often illustrate the concept of transactions. In double-entry accounting every debit requires the recording of an associated credit. If one writes a check for $100 to buy groceries, a transactional double-entry accounting system must record the following two entries to cover the single transaction:
A transactional system would make both entries pass or both entries would fail. By treating the recording of multiple entries as an atomic transactional unit of work the system maintains the integrity of the data recorded. In other words, nobody ends up with a situation in which a debit is recorded but no associated credit is recorded, or vice versa.
A transactional database is a DBMS where that provides the ACID properties for a bracketed set of database operations (begin-commit). All the write transactions within a transaction have an all-or-nothing effect, that is, either the transaction succeeds and all updates take effect, or otherwise, the database is brought to a state that does not include any of the updates of the transaction. Transactions also take care that the effect of concurrent transactions satisfies certain guarantees known as isolation level. The highest isolation level is serializability that guarantees that the effect of concurrent transactions is equivalent to a serial (i.e. sequential) execution of them.
Most modernrelational database management systems fall into the category of databases that support transactions. A new category of data stores known as NoSQL data stores has emerged during the last decade. NoSQL data stores pursue scalability and due to the lack of scalable solutions for transactional processing they renounced to provide transactions and therefore to guarantee data consistency in the advent of updates and concurrent accesses.
In a database system a transaction might consist of one or more data-manipulation statements and queries, each reading and/or writing information in the database. Users of database systems consider consistency and integrity of data as highly important. A simple transaction is usually issued to the database system in a language like SQL wrapped in a transaction, using a pattern similar to the following:
If no errors occurred during the execution of the transaction then the system commits the transaction. A transaction commit operation applies all data manipulations within the scope of the transaction and persists the results to the database. If an error occurs during the transaction, or if the user specifies a rollback operation, the data manipulations within the transaction are not persisted to the database. In no case can a partial transaction be committed to the database since that would leave the database in an inconsistent state.
Internally, multi-user databases store and process transactions, often by using a transaction ID or XID.
There are multiple varying ways for transactions to be implemented other than the simple way documented above. Nested transactions, for example, are transactions which contain statements within them that start new transactions (i.e. sub-transactions). Multi-level transactions are a variant of nested transactions where the sub-transactions take place at different levels of a layered system architecture (e.g., with one operation at the database-engine level, one operation at the operating-system level).  Another type of transaction is the compensating transaction.
Transactions are available in most SQL database implementations, though with varying levels of robustness. (MySQL, for example, began supporting transactions from version 5.5, with the switch to the InnoDB storage engine. The previously used storage engine, MyISAM did not support transactions.)
A transaction is typically started using the command
BEGIN (although the SQL standard specifies
START TRANSACTION). When the system processes a
COMMIT statement, the transaction ends with successful completion. A
ROLLBACK statement can also end the transaction, undoing any work performed since
BEGIN TRANSACTION. If autocommit was disabled using
START TRANSACTION, autocommit will also be re-enabled at the transaction's end.
One can set the isolation level for individual transactional operations as well as globally. At the READ COMMITTED level, the result of any work done after a transaction has commenced, but before it has ended, will remain invisible to other database-users until it has ended. At the lowest level (READ UNCOMMITTED), which may occasionally be used to ensure high concurrency, such changes will be visible.
Relational databases traditionally comprise tables with fixed size fields and thus records. Object databases comprise variable sized blobs (possibly incorporating a mime-type or serialized). The fundamental similarity though is the start and the commit or rollback.
After starting a transaction, database records or objects are locked, either read-only or read-write. Reads and writes can then occur. Once the user (and application) is happy, changes are committed or rolled-back atomically, such that at the end of the transaction there is no inconsistency.
Database systems implement distributed transactions as transactions accessing data over multiple nodes. A distributed transaction enforces the ACID properties over multiple nodes, and might include systems such as databases, storage managers, file systems, messaging systems, and other data managers. In a distributed transaction there is typically an entity coordinating all the process to ensure that all parts of the transaction are applied to all relevant systems.
The Namesys Reiser4 filesystem for Linux  supports transactions, and as of Microsoft Windows Vista, the Microsoft NTFS filesystem supports distributed transactions across networks. There is occurring research into more data coherent filesystems, such as the Warp Transactional Filesystem (WTF).
Manage research, learning and skills at defaultLogic. Create an account using LinkedIn or facebook to manage and organize your Digital Marketing and Technology knowledge. defaultLogic works like a shopping cart for information -- helping you to save, discuss and share.Visit defaultLogic's partner sites below: