Welcome!

Java IoT Authors: Elizabeth White, Zakia Bouachraoui, Liz McMillan, Pat Romanski, Yeshim Deniz

Related Topics: Java IoT

Java IoT: Article

Understanding EJB Transactions

Understanding EJB Transactions

EJB servers are transactional servers that allow developers to concentrate on business logic. The EJB model implements two-phase commits, transaction context propagation and distributed transaction, although it's up to the vendors to decide which technique to use.

A transaction is formally defined as an "ACID" (atomic, consistent, isolated, durable) unit of work.

  • Atomic transactions are "all or nothing." They either work or they don't – they're never left incomplete.
  • Consistent transactions always leave the system in a consistent state.
  • Isolated transactions execute in a safe manner – they won't fail if other transactions running on the same server are failing.
  • Durable transactionscan survive system failures once they're completed and committed.
For example, an online sale may involve the following steps:
  1. Begin transaction.
    Charge card sale amount.
    Update sale database.
    Update shipping database.
  2. Commit transaction.
The transaction can end in one of two ways: (1) in a commit and everything is saved; or (2) if any step within the transaction fails, the effects of all preceding steps are rolled back or undone. For example, if the shipping database can't be updated, the charge isn't made and the sale database isn't updated.

In a distributed environment handling transactions involves coordinating the various databases that participate in the transaction. In the EJB framework the bean developer can simply define the transaction policy for the bean during the deployment process, using declarative statements, and let the container handle all distributed transactions (called bean-demarcated transactions). Alternatively, the developer can take explicit control of transactions (called client-demarcated transactions).

Transactional Scope and Attributes
Transactional scope is an important part of understanding how transactions work. In EJBs the scope of a transaction includes every bean that participates in a unit of work - the bean method. The scope of a transaction can be traced by looking at the thread of execution. The transaction is propagated to a bean when that bean is invoked and included in the scope of the transaction. Of course, the thread of execution is not the only determining factor in transactional propagation; transactional attributes is the other.

An enterprise bean can take one of the following six attributes in the deployment descriptor, and the container manages the transactions according to the specified attribute. Transaction attributes can be specified for the entire bean or the bean can be fine-tuned by specifying the attributes for individual methods.

1. TX_NOT_SUPPORTED (see Figure 1): This tells the container to invoke bean methods without a transaction context. If a client invokes a bean method from within a transaction context, the container suspends the association between the transaction and the current thread before invoking the method on the enterprise bean instance. The container then resumes the suspended association when the method invocation returns. The suspended transaction context isn't passed to any enterprise bean objects or resources that are used by this bean method.

2. TX_SUPPORTS (see Figure 2): This tells the container to include the bean or method within the transaction scope in which it is invoked. If a method is part of a transactional scope and it invokes any bean with this attribute, the invoked bean and everything it accesses become a part of the transaction.

If the client invokes the bean method without a transaction context, the container invokes the bean method without a transaction context.

3. TX_REQUIRED (see Figure 3): This tells the container that the bean method must be invoked within a transaction scope. If a client invokes a bean method from within a transaction context, the container invokes the bean method within the client transaction context. If a client invokes a bean method without a transaction context, the container creates a new transaction context for the invoked bean. The transaction context is then passed to any beans that are used by this bean method.

4. TX_REQUIRES_NEW (see Figure 4): This tells the container to always invoke the bean method within a new transaction context, regardless of whether the client invokes the method within or without a transaction context. The transaction context is passed to any enterprise bean objects or resources that are used by this bean method.

5. TX_MANDATORY (see Figure 5): This directs the container to always invoke the bean method within the transaction context associated with the client. The difference between this and the TX_REQUIRED attribute is that if the client attempts to invoke the bean method without a transaction context, the container throws the javax.jts.TransactionRequiredException exception. The transaction context is passed to any beans that are used by the invoked bean method.

6. TX_BEAN_MANAGED (see Figure 6): This tells the container that the bean class doesn't have its transactional context managed by the server but it uses JTA, more specifically the javax.jts.UserTransaction, to explicitly manage transaction boundaries.

Using this attribute, however, imposes a restriction that the attributes of different methods cannot be mixed; if even one method has this attribute, then all methods must manage transaction on their own.

Making a bean transactional is expensive at runtime; since it participates in a transaction and conforms to ACID rules, its services can't be shared during the life of a transaction. Declaring a bean to be TX_NOT_SUPPORTED improves performance and may be desirable for EJBs that provide stateless service as they need to conform to the ACID rules.

Transaction Isolation Levels
The transaction isolation level determines how isolated one transaction is from another for read purposes only. These isolation levels are defined in terms of three phenomena (defined in the ANSI/ISO SQL standard -SQL92) that must be prevented between concurrently executing transactions.

  • Dirty reads: A transaction reads data written by another transaction that hasn't been committed yet. In other words, a transaction reads a database row containing uncommitted changes from a second transaction.
  • Nonrepeatable reads: A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. In other words, one transaction reads a row in a table, a second transaction changes the same row and the first transaction rereads the row and gets a different value.
  • Phantom reads: A transaction reexecutes a query, returning a set of rows that satisfies a search condition, and finds that another committed transaction has inserted additional rows that satisfy the condition. In other words, one transaction reads all rows that satisfy a SQL WHERE condition and a second transaction inserts a row that also satisfies the WHERE condition. The first transaction applies the same WHERE condition and gets the row inserted by the second transaction.

Isolation levels aren't new to EJBs; EJB defines these levels based on the ANSI-SQL92 standards. They're mapped in JDBC to the static variables defined in the java.sql.Connection interface. Isolation level, like attributes, can be fine-tuned by specifying them at the method level for EJBs; however, all methods invoked in the same transaction must have the same isolation level.

  1. TRANSACTION_READ_UNCOMMITTED: The transaction can read uncommitted data (data changed by another transaction still in progress).
  2. TRANSACTION_READ_COMMITTED: The transaction can't read uncommitted data.
  3. TRANSACTION_REPEATABLE_READ: The transaction can't change data that's being read by another transaction. Methods with this isolation level, besides having the same behavior as TRANSACTION_READ_COMMITTED, can only execute repeatable reads.
  4. TRANSACTION_SERIALIZABLE: The transaction has exclusive read and update privileges to data by locking it; other transactions can neither write nor read the same data. (This does to transaction what the synchronized keyword does to methods.) It is the most restrictive transaction.
Make no mistake – although the TX_SERIALIZABLE attribute guarantees the highest level of data integrity, it is offset by a performance slag because even simple reads must wait in line. EJBs that need to handle a large number of concurrent transactions should avoid this level. By understanding the level of reads that will occur on the database and how the database handles locking and choosing the correct isolation level, the EJB can be fine-tuned to peak performance (see Table 1).

Client-Demarcated Transactions
JTS is a specification based on the CORBA OTS 1.1 for implementing a Java transaction manager that serves as an intermediary between an application and one or more transaction-capable resource managers, such as database servers and messaging systems. The JTS specification includes the JTA API that is used by application programmers to group operations into one or more logical transactions. The Java mapping of the OMG OTS 1.1 specification is specified in two packages: org.omg.CosTransactions and org.omg.CosTSPortability. JTA actually provides three types of services:

  • Transactional operations in client applications
  • Transactional operations in application servers performed on behalf of clients
  • Global transactional management in a Java transaction manager, coordinating multiple transaction-capable resource managers such as database servers and messaging systems
EJBs use the high-level transaction manager interface provided by JTA, while the EJB server uses the JTA high-level transaction manager interface and a standard Java mapping of the X/Open XA protocol to handle transactions (javax.transaction.xa package). EJBs use the simple javax.transaction.UserTransaction interface to communicate with the transaction manager and control transaction boundaries programmatically. (The EJB specification doesn't stipulate any specific transaction service or protocol but requires that the javax.transaction.UserTransaction interface of the JTS be exposed to enterprise beans.) Important methods in UserTransaction interface are:

public void begin()
public void commit()
public int getStatus()
public void rollback()
public void setRollbackOnly()
public void setTransactionTimeout()

The UserTransaction.begin() method starts a global transaction and associates a javax.transaction.Transaction with the execution thread. It throws the NotSupportedException when the calling thread is already associated with a transaction and the transaction manager implementation doesn't support nested transactions.

The UserTransaction.commit() method completes the transaction. If at this point the transaction needs to be rolled back instead of being committed, the transaction manager does so and throws a RollbackException to indicate it.

The UserTransaction.rollback() method undoes any changes made since the start of the transaction and removes the association between the Transaction and the execution thread.

Getting Transaction Access
As mentioned earlier, the ability of the bean to access the transaction service can't be selectively applied to only certain methods of the bean. All methods must have the TX_BEAN_MANAGED attribute. That said, bean methods can get access to the transaction service through the getUserTransaction() method of the javax.ejb.EJBContext interface (the superinterface for SessionContext and EntityContext).

public void doTransaction(String customerName, String password,int
age) throws MyException{
try{
UserTransaction trans=sessionctx. ctx.getUserTransaction().begin();
Context ctx = new InitialContext();
TranstestHome home = (TranstestHome)
ctx.lookup("ejb.TranstestHome"); Transtest
bean = home.create();
bean.putUser("Sameer","word");
bean.putAge("Sameer",10);
trans.commit();
}catch(Exception e){
trans.rollback();
throw new MyException("an exception occurred" +e);
}
}

This UserTransaction also defines two methods: setRollbackOnly() and getRollbackOnly(). The first method allows the bean to veto a transaction explicitly. Once invoked, the transaction can't be committed by anyone, including the container. The second method remains true if the transaction has been so marked and can be used to avoid further unnecessary work in the method.

JTA allows the UserTransaction object to be exposed via JNDI. EJBs shouldn't use this approach as it compromises the "middleware portability"; that is, other EJB servers might not support that approach.

Context ctx = new InitialContext();
UserTransaction utx = (UserTransaction)ctx.lookup("ajndiname");
utx.begin();
// do work
utx.commit();

With entity beans and stateless session beans, a transaction managed with the UserTransaction must start and end in the same method. The reason is that entity and stateless session bean instances are shared across many clients by instance pooling and instance swapping on the server.

Stateful session beans allow the UserTransaction object to span multiple method calls because there's always one instance associated with a client, and it maintains conversational state. This bean state (and state of the transaction) is consistent even when the container makes it undergo an internal activation-passivation cycle to conserve server resources.

public class MyStatefulBean implements SessionBean {
public SessionContext ctx;

public void setSessionContext(SessionContext ctx){
this.ctx=ctx;
}
public void method1(){
ctx.getUserTransaction().begin();
// do some work
}
public void method2(){
// do some more work
}
public void method3(){
// do yet some more work
// and finally commit
ctx.getUserTransaction().commit();
}

Repeated calls to getUserTransaction() in a stateful session bean return a reference to the same UserTransaction object. Its state can be checked using a UserTransaction.getStatus() call.

Stateful session beans involve conversational state between method calls. Sometimes it may be desirable to cache this transactional state and postpone database updates. The javax.ejb.SessionSynchronization allows the server to inform a stateful session bean of the various stages in the transaction by invoking callback methods such as:

  • afterBegin(): Notifies the bean that a new transaction has started – called before the EJB delegates the business methods to the instance
  • afterCompletion(): Notifies the bean that the transaction has completed – can be used to reset instance variables since it will always be invoked
  • beforeCompletion(): Notifies the bean that the transaction is about to be committed
Client-demarcated transactions in stateful session beans across methods should be avoided since they tend to be overtly complex and any improper method invocation locks up resources. Once a stateful session bean is a part of a transaction, there's no way for it to be accessed by any other transaction context (e.g., a method with TX_REQUIRES_NEW is invoked) and the bean can't be removed. In the example above, resource locking will happen when the client doesn't invoke method3().

Exception Handling and Transactions
What happens when exceptions occur depends on the type of exception (checked or unchecked), isolation level and the transactional attribute of the bean method.

The first rule, which may sound strange, is that any exception thrown outside the transaction scope causes the transaction to roll back.

Consider an example of a client invoking a method called doTransaction() on a stateless session bean called MiddleBean. The bean internally then invokes methods on another stateless session bean called TranstestBean. The required code for these beans and the client can be seen in Listings 1 to 4. The sequence of events that occur as a result of the client call is shown in Figure 7.

The two beans are deployed with the transaction attributes shown in Table 2 and what happens as a result of these attributes is summarized in Figure 8.

In the first case the transaction context is propagated to the TranstestBean bean.

When the exception is thrown in the second bean, it falls within the transaction context; it propagates up and the container traps it in the first bean and rolls back the transaction.

In case two the second bean doesn't participate in the transaction and the transaction context is not propagated to it. The exception thrown falls outside the transaction context; the container detects this and rolls back the transaction. There is no way, however, to undo any changes made in the second bean.

In the third case the second bean has a new transaction context for each of the methods. The transaction for the exception-throwing method is rolled back, the exception moves up and the container rolls back the initial transaction. The other method executes successfully in its own transaction.

In general, methods should be logically atomic – all or nothing. If an exception is intended to indicate that the method can't complete successfully, it shouldn't be caught. If it is caught, the method should try to correct the problem and continue. The method must throw the exception and propagate out of the method for the transaction to be rolled back.

Application exceptions won't cause a rollback if they're thrown and caught within the transactional scope. Runtime exceptions or unchecked exceptions, on the other hand, always cause a transaction to roll back, regardless of the transaction attribute or transactional scope.

Unilateral Decisions
The transaction manager allows certain heuristic or speculative decisions to be made based on the state of all participating resources in a transaction and the underlying two-phase commit protocol. A heuristic decision occurs when one of the resources in the transaction unilaterally decides to commit or roll back the transaction without permission from the transaction manager. This breaks the atomicity of the transaction and is captured by the manager in the following exceptions:

  • javax.transaction.HeuristicCommitException is thrown when a rollback is requested but a heuristic decision was made and all updates were committed.
  • javax.transaction.HeuristicMixedException is thrown when a heuristic decision was made and some updates have been committed and others were rolled back.
  • javax.transaction.HeuristicRollbackException is thrown when a commit is requested but a heuristic decision was made and all relevant updates were rolled back.
Resources
  1. A complete definition of two-phase commits by SEI: www.sei.cmu.edu/activities/str/descriptions/dtpc_body.html
  2. Datamation Magazine. "What a two-phase commit is and how it works": www.datamation.com/datab/twophase.html
  3. SQL 92 standards: www.ansi.org
  4. Java Transaction API: http://java.sun.com/jta
  5. EJB home page at SUN: http://java.sun.com/products/ejb
  6. The Oracle technical network: http://technet.oracle.com/
  7. The org.omg.CosTSPortability and other similar packages: http://java.sun.com/products/jts/javadoc/org/omg/CosTransactions/package-summary.html
  8. Complete source code, console dumps, SQL test queries and UML diagrams: www.JavaDevelopersJournal.com

More Stories By Sameer Tyagi

Sameer Tyagi, an enterprise architect, focuses on strategy, design, and implementation of large-scale enterprise applications. His publications include several books and periodicals on technology. He can be reached at http://sameertyagi.blogspot.com.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


IoT & Smart Cities Stories
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...