Introduction :-
Most of the Enterprise applications are accessed by many numbers of clients simultaneously and the developer has to provide both functionality and performance to users. With that in mind, how do we ensure that consideration for performance does not compromise data integrity? i.e. there needs a mechanism to deal with multiple users accessing data concurrently.
Enterprise applications often try to balance application scalability with concurrency considerations. You can achieve scalability using many different techniques, including minimizing network traffic.
This article describes the Locking pattern in two parts. Part 1 of the article explains transactional overview, transaction demarcations and then describes Container Managed Transaction Demarcation in detail.
Part 2 of the article explains the locking methodologies, how it is implemented in SAP J2EE Engine of WAS and how it solves concurrency issues.
Transactional Overview :-
Transactions represent a fundamental unit of work for managing business complexity. At its most basic, a transaction is a series of operations that appears to execute as one large atomic operation. A typical business application has many associated transactions. Once the transaction begins either it ends with either commit or abort.
Transactions ensure the integrity of an application's business rules, a process that gives rise to transaction processing (TP) applications that execute multiple transactions simultaneously. Transactions allow multiple users to share the same data and guarantee that any set of data they update are completely updated without interleaving other clients to modify it.
As an application example, consider a train ticket reservation system. In our example, when a passenger wants to book a seat, the following sequence of actions must happen: • An open seat must exist • A ticket must be issued • The passenger must be billed via a credit card using Electronic Data Interchange (EDI) • That seat must be removed from the available seats list This system quickly raises concurrency, scalability, and consistency concerns when multiple users try to make reservations on a distributed system.
To simplify the potential complexity, consider the entire train booking process as one unit of work -- a transaction. A transaction comprises four critical properties: • Atomic • Consistent • Isolated • Durable
Together, the four critical properties produce the ACID acronym.
In the context of our example, consider a transaction atomic if it executes either completely or not at all. For example, if no seat exists, the entire transaction aborts or rolls back to the transaction's start. When a transaction rolls back, the database returns to the state it had prior to the transaction's inception. Atomicity guarantees that many operations are tied together and appeared as one contiguous unit of work.
Moving on to isolation, consider a transaction isolated if the transaction executes serially. In other words, it should appear as if the transaction runs alone with no other transaction occurring simultaneously. This guarantees data integrity. During transactions, locks on data are automatically assigned as necessary. If one transaction holds lock on the data, then lock prevents other transaction to concurrently manipulate the data until the lock is released.
A transaction must also be durable; a permanent record of the transaction must persist. It must ensure that updates to resources such as data base survives system crashes. For optimization purposes transactional records are often kept in memory. However, the transaction cannot be considered ACID until the data is written to permanent storage.
Although second on the list, the last term of an ACID transaction to consider is consistent. A transaction ensures consistency if it is atomic, isolated, and durable. If a train possesses 100 seats and each seat sells for $100, then at the end of 10 successful transactions the railway's account should have $10000 more than it did when it started. If this is the case, the database is in a consistent state. Another example can be a bank account may not have negative balance even though during transaction processing a bean may make it negative temporarily while withdrawal, but at the completion of transaction the bean never leaves it negative.
Transaction demarcations :-
Transaction demarcation describes who begins transactions, who issues either commit or rollback, and when each of these steps occur.
You can demark EJB transactions in three ways: 1. By the client 2. By an EJB 3. By a container
Demark by the client :-
In this type of demarcation, the code to start and end transactions is written in the client code, outside of the bean. If the client that is using the bean is either a servlet, jsp or an enterprise bean itself then you can begin and end the transaction in that client.
Demark by an EJB :-
When using demarcation by an EJB ,the application programmer is responsible for coding transaction logic into the application code.That is the programmer has to issue a begin statement, either commit or abort statement.
Demark by the container :-
This is also called as declarative transactions allow for components to be automatically be enlisted in transactions. In this case, you define a method's transaction attributes in an XML deployment file. This is the preferred way to define transactional behavior with EJBs. You can manage changes in transactional behavior by modifying deployment descriptors, thus minimizing propagation of code changes.
Container Managed Transaction Demarcation :-
Every enterprise bean must have a transaction attribute setting. Every client method invocation on a bean is supervised by the bean’s container,which makes it possible to manage the transactions according to the transaction attributes that are specified in the corresponding bean’s deployment descriptor. A particular transaction attribute can be associated with an entire bean and apply to all its methods or just with an individual method. The scope of the transaction is defined by the transaction context that is shared by the participating bean objects.The following are the possible values for the transaction attributes in the deployment descriptor. • Not supported • Supports • Required • Requires new • Mandatory • Never
Not supported :-
If a method associated with the TX_NOT_SUPPORTED transaction attribute is invoked in the scope of a client transaction, the transaction is suspended during the method execution. Supports :-
When a bean is called with TX_SUPPORTS transaction attribute , it runs only in a transaction if the client had one running already, it joins that transaction. If the client does not have a transaction ,the bean runs with no transaction at all. Required :-
Bean methods marked with TX_REQUIRES must be invoked within a transaction's scope. If a transaction already exists (that is, the method is called from a client as part of an existing transaction), the Required bean method is included in the scope of the current transaction. If it is not called within the context of a transaction, then a new transaction scope is created and the Required bean method is added to that new transaction. Requires New :-
Beans with TX_REQUIRES_NEW transaction attribute, a potential client transaction is suspended during the execution of the method associated with this attribute, and the method is executed in the scope of a new transaction created by the container. If no error occurs, the transaction is committed, otherwise it is aborted. The client transaction is then resumed. Mandatory :-
Mandatory mandates that a transaction must be already running when a bean method is called. With a call without a specified Transaction context,the EJB container throws a javax.transaction.TransactionRequiredException. Never :-
The Never transaction attribute means that the bean cannot be involved in a transaction.If this happens, the EJB container throws a java.rmi.RemoteException with remote access and javax.ejb.EJBException with local access. Conclusion :-
Thus the article gives an detailed introduction of Transactional Overview, Transaction Demarcations and Container Managed Transaction Demarcation. In the next blog, we will see the locking methodologies and how it is implemented in SAP J2EE Engine of WAS for solving concurrency issues.
