EJBs guarantee ACID

With EJB you can avail of the benefits of transactions without coding to any transaction API.
To perform an atomic transaction in the simplest way would be to add code to the catch clause of a try block that encloses the transaction.
In the catch block you would try to undo whatever was done in the try block but this is a primitive way of conducting a transaction and would be prone to many errors and bottlenecks.
Problems that may need transactions:
1. Network crash
2. Database crash
3. The machine on which the database is installed itself might crash
4. Data consistency during simultaneous data access
Points 2, 3 and 4 might lead to corrupted data.
A transaction is a series of operations that appears to execute as one single atomic operation.
Transactions guarantee that all your operations in the transaction succeed or none at all.
Transactions guarantee ACID:
· Atomicity
Atomicity guarantees that all the operations in a transaction such as those involving session/entity beans, a CORBA client, a servlet, a database driver are completed or not at all. This is similar to a voting scheme if any of the constituent transactions fail the complete transaction fails.

· Consistency
Though operations inside a transaction may leave a system in a temporarily inconsistent state, in the end the system is always consistent so that to a third party the system has always remained consistent.

· Isolation
Each user accessing data need not know about other user actions on the same data. They seem to operate in isolation to each other thus ensuring data consistency using low-level synchronization that involves temporary locks on the database.
This ensures that several users can safely access the database concurrently without data corruption.

· Durability
Durability ensures that updates to system-managed resources such as a database survives system failures including power failure, machine failure, network failure or disk crashes by reapplying the steps maintained in a transactional log file maintained for this purpose.

Transactional Models

The two most popular transaction models are 1. Flat transaction and 2. Nested transaction
Nested transactions are not supported by all EJB servers

Flat transactions:
A flat transaction is a series of transactions that is performed as one unit of work. Either the entire atomic transaction is committed or rolled back. All operations that are performed in the transaction are undone in a rollback.
Flat transactions may be rolled back for any of the following reasons:
1. Invalid parameters passed to one of the components
2. System consistency is compromised
3. Hardware/ Software failures

Nested transaction:
This consists of independent sub transactions within a main transaction, which can be independently rolled back without affecting the main transaction. This allows users to perform units of transactional activity within a main transaction without letting the entire transaction fail.

Types of transactions:

1. Programmatic transactions

With a programmatic transaction it is the programmer who decides when to start a transaction and when to end it. He issues a begin statement to start a transaction and a commit or abort to end the transaction.

The advantage of using programmatic transactions is that you can have any number of sub transactions within the main transaction which is not possible with declarative or client controlled transactions.

With programmatic transactions all you would need to deal with is the Java Transaction API. (JTA)

With JTA you can control several things such as when to start a transaction and when to issue a commit or abort.
Client code can also use the JTA.
.begin() To start a transaction
.commit() commits a transaction
.getStatus() gets the status of the current transaction under which the bean is running
.rollback() forces a rollback
.setRollbackOnly forces the current transaction to rollback, eventually causing the transaction to abort.
.setTransactionTimeout(int) will force the transaction to abort after specified amount of time elapses

public void dothis()

	javax.transaction.UserTransaction jta=null;
	//Do something
   }catch(Exception e){

If you are participating in a transaction that someone else started (not declarative but container managed) you cannot explicitly call rollback() to end the transaction.
In declarative transaction the best way to do this would be to call setRollBackOnly() on your EJB context object.
If you want to doom a transaction running on a non EJB object, such as a java object, then you can call the JTA’s setRollBackOnly()

2. Declarative transactions

In this case the enterprise beans never issue the call for starting or ending a transaction but it is the EJB container that is responsible for doing so. EJB allows you to declare whether your bean is enrolled in a transaction by declaring it in the ejb-jar.xml deployment descriptor.
This is done within the transaction-type tag nested in the session tag where the user either specifies Container or Bean. Declaring the transaction as bean would imply programmatic transaction.

Declarative transactions allow you to initiate transactions without hard coding it in the bean/client code.

You must specify transaction attributes on all the business methods for your beans Further more with entity beans you need to specify transactional attributes for home methods too.

This attribute joins a transaction only if one exists. If no transaction was running the bean runs without any transaction.
Be careful to use this attribute under mission critical applications.

This ensures that your bean is never run under a transaction.
If a transaction is running it is suspended when your bean is called.

is used if you want your bean to always run under a transaction.
If you call session beans B and C from a bean A, and if A and B have “required” transactional attributes B joins the transaction initiated by A as soon as B is called. If A then calls C which also has a “required” transactional attribute, C too joins the transaction.
Thus “required” transactional attribute allows you to initiate a transaction or join an existing transaction depending on the circumstances.

This attribute ensures that always a new transaction is initiated.
If a transaction is already running, that transaction is suspended and a new transaction started. When this transaction ends the old transaction resumes.
Of course if there was no transaction initiated, there is nothing to suspend or resume.

Mandatory mandates that a transaction should already be running when a transaction is called, otherwise it throws an exception.
This is the chief difference between mandatory and supports.
It is useful to use this attribute when you are running a sub transaction within a main transaction and you want to ensure that a transaction was initiated before your bean was called.

This ensures that your bean is never run under a transaction and if it is run it throws an exception.
This is the chief difference between “never” and “notsupported”.
This attribute is useful if you want to ensure that your beans are never called within at transaction in your client code.

3. Client Initiated Transactions

In this case the transaction is initiated and closed within the client code that calls the beans. The client may be a servlet, applet, CORBA client or another bean.
The client calls would still need to be done using declarative or programmatic transactions.

Try not to use client-controlled transactions as frequently the transaction may be rolled back due to conflicts.

Bean managed transactions are illegal for entity beans and is always container managed.

It is a good design strategy to include maximum number of entity bean calls within a transaction in your session bean / client code.

You can use JTA to control transactions in the client code.
First you lookup the JTA interface using JNDI.

	Context ctx=new InitalContext();
	jta= (javax.transaction.UserTransaction)ctx.lookup(“jndi name”);
	//do something
}catch(Exception e){

About cuppajavamattiz
Matty Jacob - Avid technical blogger with interests in J2EE, Web Application Servers, Web frameworks, Open source libraries, Relational Databases, Web Services, Source control repositories, ETL, IDE Tools and related technologies.

Comments are closed.

%d bloggers like this: