Transaction Management Concepts –
What does Transaction mean?
A transaction, in the context of a database, is a logical unit that is independently executed for data retrieval or updates. In relational databases, database transactions must be atomic, consistent, isolated and durable these four referred as ACID properties.
If we consider a business transaction, a program may need to perform several steps. A financial program, for example, transfer funds from a checking account to a savings account using the steps listed in the following pseudocode:
begin transaction
Checking debit balance
debited source account
credited destination account
update transaction log
commit transaction
Either all three of these steps must complete, or none of them at all. Otherwise, data integrity is lost. Because the steps within a transaction are a unified whole, a transaction is often defined as an indivisible unit of work.
A transaction can end in two ways: with a commit or with a rollback. When a transaction commits, the data modifications made by its statements are saved. If a statement within a transaction fails, the transaction rolls back, undoing the effects of all statements in the transaction.
ACID Properties:
Atomicity: A transaction must be completed successfully(committed) or completely undone(rolled back). Fund transfer in a online banking illustrates a scenario which explains atomicity, e.g., the ammount must be deducted from senders account and debited to receivers account. Both either happen together or do not happen – it’s all or nothing.
Consistency: The transaction must be fully compliant with the database. In other words, the transaction cannot break or violate the database’s constraints. For example, if a database table’s Account Number column can only contain numerals, then consistency dictates that any transaction attempting to enter an alphabetical letter will not be commited.
Isolation: Transaction data must not be available to other transactions until the original transaction is committed or rolled back.
Durability: It means that once a transaction is complete, it must be stored in durable medium like hard disk. Also the transaction data changes must be available, even in the event of database failure.
Transaction Propagation:
Required – If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method. Most container-managed transactions use Required.
RequiresNew – If the client is running within a transaction and invokes the enterprise bean’s method, the container suspends the client’s transaction, starts a new transaction, delegates the call to the method, and finally resumes the client’s transaction after the method completes. If the client is not associated with a transaction, the container starts a new transaction before running the method.
Mandatory – If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container throws the TransactionRequiredException. Use the Mandatory attribute if the enterprise bean’s method must use the transaction of the client.
NotSupported – If the client is running within a transaction and invokes the enterprise bean’s method, the container suspends the client’s transaction before invoking the method. After the method has completed, the container resumes the client’s transaction. If the client is not associated with a transaction, the container does not start a new transaction before running the method. Use the NotSupported attribute for methods that don’t need transactions. Because transactions involve overhead, this attribute may improve performance.
Supports – If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container does not start a new transaction before running the method. Because the transactional behavior of the method may vary, you should use the Supports attribute with caution.
Never – If the client is running within a transaction and invokes the enterprise bean’s method, the container throws a RemoteException. If the client is not associated with a transaction, the container does not start a new transaction before running the method.
Transaction Isolation:
This is one of the four ACID properties in a DBMS. The default isolation level of different DBMS’s varies but most databases allow the user to set any isolation level.
1) Serializable
This is the top most isolation level.
With a lock-based concurrency control DBMS implementation, serializability requires read and write locks (acquired on selected data) to be released at the end of the transaction. Also range-locks must be acquired when a SELECT query uses a ranged WHERE clause, especially to avoid the phantom reads phenomenon.
When using non-lock based concurrency control, no locks are acquired; however, if the system detects a write collision among several concurrent transactions, only one of them is allowed to commit. See snapshot isolation for more details on this topic.
2) Repeatable reads
In this isolation level, a lock-based concurrency control DBMS implementation keeps read and write locks (acquired on selected data) until the end of the transaction. However, range-locks are not managed, so the phantom reads phenomenon can occur (see below).
3) Read committed
In this isolation level, a lock-based concurrency control DBMS implementation keeps write locks (acquired on selected data) until the end of the transaction, but read locks are released as soon as the SELECT operation is performed (so the non-repeatable reads phenomenon can occur in this isolation level, as discussed below). As in the previous level, range-locks are not managed.
Putting it in simpler words, read committed is an isolation level that guarantees that any data read is committed at the moment it is read. It simply restricts the reader from seeing any intermediate, uncommitted, ‘dirty’ read. It makes no promise whatsoever that if the transaction re-issues the read, it will find the same data; data is free to change after it is read.
4) Read uncommitted
This is the lowest isolation level. In this level, dirty reads are allowed, so one transaction may see not-yet-committed changes made by other transactions.
Since each isolation level is stronger than those below, in that no higher isolation level allows an action forbidden by a lower one, the standard permits a DBMS to run a transaction at an isolation level stronger than that requested (e.g., a “Read committed” transaction may actually be performed at a “Repeatable read” isolation level).
- Salesforce Certified Platform Developer I – Winter ’18 Release Exam - November 23, 2017
- Salesforce Certified Platform App Builder – Winter ’18 Release Exam - November 22, 2017
- Salesforce Certified Administrator – Winter’ 18 Release Exam - November 21, 2017
