A transaction must have four fundamental characteristics, summarized by the acronym ACID (atomicity, consistency, isolation, durability), to correctly implement its function. Its main goal is to maintain the correctness and consistency of the data during the operations of alteration of the status of the business domain.

The characteristics are as follows:

• Atomicity: This property means that all operations that are included in a transaction must be executed as if they were a single block. With this behavior, the application has the ability to abort a transaction if an exception occurs, and to have all writes (performed by insert, update, and delete operations) discarded, preserving the original integrity state of the data. Otherwise, when the transaction commits successfully, all operations of a transaction must execute a valid commit of the operation (be it database writing, message consuming, and so on). Conversely, when the transaction fails, the system must be able to roll back the original status of the data, and all realized operations and effects must be undone.
• Consistency: This property is related to the logical consistency of the data. When a new transaction starts, it must ensure that the data maintains a state of logical consistency, regardless of the final outcome (commit, abort, or roll back). In reality, the concept of logical consistency cannot be translated into a universal, semantic algorithm, applicable by a transaction manager; it is a state that is linked to the business domain implemented by the application. We can define it as a human concept; therefore, there is no semantic knowledge to be applied by the container. The only way to implement this concept is to restore the initial state of the data (in case of a failure), or to ensure that all operations are completed, bringing the data to a new state, if successful.
• Isolation: This property is related to the execution of parallel transactions on the same resources. It guarantees that concurrent transactions cannot interfere with one another, like what happens for the thread-safe code. Each transaction behaves as if it was executed entirely alone. The serial execution of each transaction guarantees a consistent state, while the execution of parallel transactions cannot result in an inconsistent state of the data. The relational databases that follow the standards described in ANSI SQL-92 implement four levels of isolation with a different implementation of the locking mechanism. The four levels are as follows:
  • Read uncommitted: This is the lowest isolation level. Setting this property, the transaction only sets the lock when it needs to update the record item and releases it after the transaction is terminated. It's usually defined as long write locks. This behavior allows one transaction to read the changes of any other transactions that are not committed (a dirty read). However, it avoids the dirty write problem, which happens when a transaction overwrites a value that was previously written by another transaction and has not been committed yet.
  • Read committed: Using this property, the application is able to avoid the dirty reads phenomenon. This isolation level allows the read of data only when it has been committed. It is the main model that's used in enterprise applications.
  • Repeatable read: This isolation level prevents the phenomenon called non-repeatable read that can happen with the read committed setting. It involves reading the data values over different periods, during which a consistent data state may not be guaranteed. This means that, for example, a transaction could know of a data change at a later point in time: this could invalidate the data that was read during previous processing.
  • Serializable: This property specifies that one transaction is unable to read the data that has been modified by another transaction, but has not yet been committed. If you want to obtain the same result without setting this value you should implement a model that guarantees that no other transaction can insert new data that has a primary key with values that could fall within a key range read from any statement. So you should choose if delegate this behavior to the database or to implement a custom solution yourself.
• Durability: This feature requires that all of the changes be made during a transaction; once it is committed, it must be persistent and definitive, even in the case of system crashes. Usually, the use of persistent storage, like a disk drive or the cloud, is sufficient.

In addition to the specific elements that each solution uses to implement ACID properties, you may have noticed that the common denominator is a lock, which is not one of the factors that allows us to obtain a high level of scalability in an architecture.

Who is the actor that handles the transactions? The answer is—the transaction manager.