Scaling J2EE Technology Applications Based on Application Infrastructure Techniques - Part 3
March 16, 2001

by Rakesh Radhakrishnan

This article is the third in a four-part series that identifies multiple techniques for scaling applications based on J2EE technology to support many concurrent users.

Scaling Techniques

Database Server - System Level Clustering and Parallel Databases (e.g., Oracle 8i)
The ideal approach to scaling the database management system is vertical (scaling the DB system between CPUs within a server). If horizontal techniques are used with data partitioning and distributed transactions, database synchronization typically becomes a significant issue.

Most DBMS (relational and object-relational) can scale vertically within a box due to the multiprocess and multithreaded architecture of these systems. Figure 13 illustrates a typical single-node configuration.

Figure 13: Typical single-node DBMS configuration (Click image to enlarge.)

Some of the best TPC-C benchmarks are accomplished on single-node configurations that support several hundred thousand transactions per minute.

In cases where the vertical scalability is not sufficient, horizontal scalability can be achieved via system-level clustering and parallel databases (when two or more nodes are submitting transactions to the same database), as shown in Figure 14.

Figure 14: Parallel databases (Click image to enlarge.)

Scaling can extend further based on the I/O characteristics of the database. If the database is more read- than write-intensive, it is easier to introduce a 4-node cluster, with 3 read nodes and 1 write node on a SAN (storage area network) topology, as shown in Figure 15.

Figure 15: Database clustering (Click image to enlarge.)

This approach to scaling is appropriate for read-intensive databases; if the database is write-intensive or equally balanced, more nodes should be added to handle writes. Distributed lock manager (DLM) plays an intricate role in such configurations. DLM ensures data integrity when two are more nodes are submitting transactions to the same database.

It's also possible to accomplish database system scaling via data partitioning. In data partitioning, the data is sliced into manageable pieces (for example, based on geography, alphabetic groups, etc.). This partitioned data is then managed by its own dedicated database management system.

Messaging Server - Redundant Processes and Distributed Queues (e.g., Tibco)
Messaging servers based on Java Message Service technology (JMS) are capable of sending and receiving messages to and from Java and non-Java applications (within the same message domain) on any platform via both publish/subscribe and request/reply models. These systems are mission-critical because they form the foundation of message-based Enterprise Application Integration (EAI) -- integration between multiple applications deployed within a single enterprise's network.

Messaging systems typically utilize a distributed architecture to eliminate bottlenecks and single points of failure. Applications require reliable message relaying, certified and transactional, as appropriate for each message exchange. Messaging can be synchronous or asynchronous, locally delivered or sent via a WAN or the Internet. Generally speaking, messages are self-describing and platform-independent.

Scaling the messaging platform relies on redundant processes and distributed queues. When messages are sent from one application to another, two or more redundant messaging processes receive the message, and distributed queues are built up at the same time. This configuration is shown in Figure 16.

Figure 16: Messaging using redundant processes and distributed queues (Click image to enlarge.)

To ensure that the message is not applied twice to the receiving application, there is a one-in-n delivery algorithm built into the messaging platform. Essentially this ensures that one successful attempt is propagated to all redundant processes. JMS-based systems optionally support distributed transactions based on Java Transaction Service (JTS).

Transaction Server - Data-dependent Routing and Request Prioritization (e.g., BEA Tuxedo)
Transaction servers enable applications and application servers to control the scope and duration of transactions and coordinate transaction completion across transaction managers. At a low level, JTS complies with Object Management Group's (OMG) OTS 1.1 (object transaction server) specifications and in certain cases meet XA compliance. While JMS is used for integrating loosely-coupled applications, JTS is for tightly-coupled applications.

The scalability of the transaction servers is built into these systems based on techniques such as data-dependent routing and request prioritization.

Data-dependent Routing
Data-dependent routing is a technique in which a transaction-service request is mapped to a specific server group (physical and/or logical) based on a value contained in a designated field within the data buffer. Transaction-server groups are mapped to specific resource manager/database instances, and a transaction request is routed to that specific service/resource manager combination.

Here's an example. A bank database may be horizontally partitioned by account number, with different ranges of accounts stored in separate, dedicated database instances. Instead of coding the specific partitioning information into the application code for accessing the accounts, you can use the JTS-based transaction manager data-dependent routing. In effect, the transaction manager looks at the specified data value, consults routing information stored in a tool such as a bulletin board, and dispatches the request to a database instance operating on the correct data partition, as shown in Figure 17.

Figure 17: Transaction server example (Click image to enlarge.)

If changes are made to the database partitioning (migrating a partition to a new server, or changing the distribution of accounts across existing partition instances), one needs only to change the transaction manager data-routing information. The application code is isolated from this issue. From this standpoint, the transaction service offers tremendous value as middleware between applications, application servers and different data stores.

Request Prioritization
Request prioritization is another core capability offered by JTS-based transaction managers/servers. Transaction-service requests often require a higher priority than others. For example, in an airline reservation system, an airline seat cancellation has a higher priority than a seat reservation: for most airlines, canceled seats must be rebooked as soon as possible. Transaction-request prioritization occurs at the service-queue level as illustrated in Figure 17. The transaction services offered by the JTS-based transaction server are scalable and do not impact the performance of high-priority transactions via this technique.