Enterprise software developers and corporate IT architects have established the Java Enterprise Edition (JEE) platform as a leading choice for building enterprise software applications. The platform is widely used for everything from eCommerce Websites to back office data aggregation systems. Its versatility and reliability as an enterprise computing platform is well established.

But this wasn't always so. Sun initially trumpeted Java as a desktop platform that would bring rich content to Web applications in the form of Java applets that run locally in a user's Web browser. It was also touted as a thick-client desktop application development tool that would be widely used to build applications that could run on any computer (remember write once, run anywhere?).

Sometime in the late nineties, Java application development took a 90 degree turn and ended up resulting in software that mostly runs on corporate servers instead of corporate workstations. Today, a substantial portion of Web applications are delivered on the JEE platform.

Despite the "Enterprise" in its name, the JEE platform was principally designed for handling HTTP requests from Web browsers and performing some business logic in response to each request. It now includes many other technologies, but most of them are related to this mission.

However, as the complexity and disparate uses of Web applications has grown, users and designers of these systems have found many users for JEE beyond just responding to requests from a browser. Many of these uses include common enterprise back office tasks such as batch processing of large volumes of data, and while the JEE platform was not originally designed for such purposes, it is versatile enough to provide viable solutions to these problems.

What Is a Batch?
Batch scenarios arise often in business software applications because of a conflict between the enterprise's desire to respond immediately to customer requests and also analyze the resulting transactions. This requires the speedy capture of the initial transaction with no analysis and then a later batch process to aggregate or optimize the data for reporting, analysis, archive or some other large volume process. It is a safe assumption that every business in the world does some kind of batch processing on their data.

The characteristics of the typical batch process include:
  • A long-running process that must occur on a regularly scheduled basis.
  • The volume of data to be processed is high, usually on the order of thousands to millions of database rows.
  • There may be complex logic or calculations to perform on the data.
  • The process may require a large set of data from some other system that is delivered at a specific time in a large set.
  • The process is run asynchronously from user interactions. It's not part of a user session in an online system. A user does not start it and is not waiting on it to complete.

Why Do Batch Processing in JEE?
The JEE specification was designed for online Web applications and has several limitations with respect to batch processing. For instance, JEE containers are required to manage the life cycle of Enterprise JavaBeans (EJB) and as such might limit the ability to create threads from within these classes.

However, this limitation can be overcome in a couple ways. First, while most JEE containers discourage developers from creating and managing their own threads, they do not prohibit the practice, especially outside the bounds of EJB classes. Therefore, the batch process can do its own threading using the java.util.Concurrent package (available as of Java 5) and on most JEE platforms this causes no trouble. This package provides user-friendly thread pool classes and thread management facilities that make it easier than ever to create multi-threaded applications in Java.

Second, a more spec-compliant approach to multithreading is to use Java Message Service (JMS) messages to create worker threads within the JEE context. This approach is a little more complex to implement but provides the benefits of complying with the JEE specification while also allowing the batch process to span multiple Java Virtual Machine (JVM) instances in a clustering situation. This will be discussed in more detail below.

Another issue with batch processing on the JEE platform is that by default the container manages transactions and session timeouts. The JEE container is inclined to limit how long resources such as database connections, transactions and beans can be monopolized. This is meant to guarantee a high level of service to all users within an online application, but can be problematic for a long-running batch process.

This issue can be addressed by correctly configuring a batch process not to require JEE transactions and to avoid the use of entity beans and stateful session beans that might have timeout or locking problems. Also, be sure to use the pooled resources such as database connections judiciously, releasing them back to the pool when not in use.

In addition to these limitations there is a performance question. Other methods can achieve higher performance than the JEE platform. Batch processing typically involves operations on large volumes of rows stored in a relational database, and a stored procedure implemented directly in the database might offer the fastest performance for most applications. However, there are legitimate reasons to implement the logic in JEE instead.

  • Stored procedures are typically implemented in the version of SQL specific to the database platform and are not portable to other databases. This may not matter for a departmental application but is usually not acceptable for an enterprise software product that must be supported on many different databases.
  • The JEE platform provides complimentary technology such as JCA connections to other systems, Web service calls to other services and other features that might be useful.
  • Logic implemented in Java can reuse other application logic that is also present in the business layer tier of the application.
  • Well-written Java code is usually easier to understand, maintain, and enhance than a collection of stored procedures.
  • JEE servers usually include clustering capabilities that provide the ability to federate multiple, cheap, commodity servers to improve batch processing performance.

These benefits will often outweigh any performance gain that might be achieved using stored procedures. Furthermore, the difference in performance between a Java solution and a database stored procedure solution can be minimized using the techniques described below.

Techniques for High-Performance Batch Processing on JEE
Now that we've covered the limitations and the alternatives, let's discuss how to architect a batch process on the JEE platform for maximum performance. Batch problems are clearly candidates for multi-threaded solutions because the objective is to complete as much work as possible in the shortest time possible and no human user interaction is necessary. Parallel processing using multiple threads is necessary to bring all available computing resources to bear on the problem. Today's multiple core, multiple CPU servers are especially well suited for multi-threaded processing.