11.6. Putting It All Together

Oracle JDeveloper, a powerful interactive development environment for creating Java applications, was used to great benefit in creating this EJB application. It's wizards allowed rapid creation of the EJB components, and its integrated debugger supported debugging EJB implementations, even when running within the database. When the project-wide JNDI namespace was defined, the built-in JNDI browser allowed convenient access to entities within (see Figure 11.14).

11.6.1. The Oracle Enterprise Java Engine (Oracle EJE)

The choice of Java virtual machine can have a large influence on the overall performance and stability of a Web application written in the Java programming language. Oracle has addressed this problem by developing its own Java virtual machine implementation that runs within each server product—Oracle9i database and Oracle9iAS. By running within the database, Java applications can leverage all the scalability and reliability of the database server. In the application server, Oracle EJE runs within the mid-tier SQL cache, allowing the data proximity benefits to exist in the application server as well. It is the only JVM implementation that uses the scalability of an RDBMS to be able to support thousands of concurrent users.

The developers of Oracle EJE have been able to make significant improvements compared with traditional Java virtual machines designs. For example:

• Accelerator^[2]

  ^[2] Accelerator has been used to natively compile all the standard Java classes provided with the JVM. It became available for application developers to compile their own classes in Oracle8i Release 3 (version 8.1.7).

  An innovative feature of Oracle EJE is its use of native compilation. In a server environment, the portability offered by interpreted Java bytecode is not necessary. Server applications are typically longer lived than those of a client, which means it is worthwhile investing more CPU cycles to produce highly optimized native code than could be done by a just-in-time compiler such as HotSpot. Native code compilation can significantly improve server performance.

• Generational Scavenging Garbage Collector

  Oracle EJE uses an advanced garbage collection strategy that greatly improves the memory utilization of Java applications.

  A generational garbage collector (GC) distinguishes objects by their ages in various memory spaces (new space, old space). Objects in older spaces are less frequently reclaimed than objects in newer spaces. OracleJVM allocates and manages memory at the individual session level, without any impact on other sessions, providing stable and predictable behavior (as opposed to thread-based virtual machines in which all threads stop during GC).

• Scalability

  Oracle has made significant advances in reducing the amount of memory required for a typical stateful Java session. On Oracle EJE, each session appears to be running on its own private JVM, yet the memory overhead is typically under 50K.

  Sessions are per-user memory structures used to keep the user's state across calls. Scalability in OracleEJE is enabled by the execution framework that allows a large number of sessions to be scheduled and executed by a small number of shared servers.

• Database Integration

  Because most e-business Web sites typically involve extensive use of relational databases, it is vital that Java applications efficiently access the database. By integrating the JVM within the database, the communications overhead imposed by running in an external JVM is eliminated. Oracle has also supplied a special “server” JDBC driver that can be used to directly access the database's SQL engine through the same high-performance APIs that were previously available only to PL/SQL-stored procedures.

Oracle EJE is a relatively new feature, yet the CERN team has used it successfully in production with EDH for the past two years and found it to be a very stable implementation.

11.6.2. Java Virtual Machine Overload

One area that was identified very quickly when developing EDH was the need to spread the load of the application on several Java virtual machines at the same time. This was because a single virtual machine rapidly became overloaded with only a relatively small number of users. The problem usually manifested itself with the virtual machine running out of available memory, even though it had been allocated 64 MB of RAM. This is because the virtual machine gets loaded and the garbage collector fails to keep up with the number of objects being freed. The result is that new memory allocation calls fail, even when there is plenty of free memory (albeit, all of it waiting to be marked free by the garbage collector).

In the past, this problem was solved by spreading the user population across several virtual machines (up to 20) running on the same host. This effectively created 20 garbage-collector threads, each managing a smaller pool of objects. This type of load balancing is necessary on any large-scale, Java technology-based Web application, and can significantly complicate its design.

With Oracle EJE memory architecture, this scheme is no longer necessary; in fact, each session (user) runs in its own virtual VM. Typical thread-based servlet engines use threads to isolate concurrent users. This becomes a bottleneck when there are a large number of users and a stateful application. True, a good design will limit session state to only the essentials; however, even this can cause resource (thread) contention within the container. Oracle's approach is to use a virtual machine architecture that isolates concurrent users. The result is less contention and a container that is more resilient to application failures within an individual session.

In addition, when many users share the same virtual machine, it is almost impossible to prevent the activity of one user from affecting the others. By using Oracle EJE, however, the resources consumed by a session can be strictly controlled using standard Oracle tools. Limits on memory, CPU, and other resources can all be set.

11.6.3. Load Balancing

Another area identified when developing EDH was the need to understand how load balancing is handled by the platform on which J2EE components are deployed. This led to an effort to understand how the server platform dealt with response times and how Oracle9i platform distributes connection loads across multiple servers to provide no single point of failure. Oracle's clustering technology is used to load-balance and provide fault tolerance.

Oracle supports several load balancing techniques.

• Round-Robin DNS for distributing HTTP requests across the cluster. This simple mechanism works well for Web traffic in which multiple IP addresses are assigned for the same name in the DNS name space. Requests are alternated among the hosts that are presented in rotational order.

• Use of hardware load-balancing devices and IP sprayers. In order to address the scalability problem, a router, or IP-sprayer is placed between the clients and a cluster of application servers to spread the load evenly over the nodes.

• Spawning a number of HTTP processes to handle load. Spawning multiple HTTP processes increases the ability of the server to handle thousands of client requests. Load balancing is used to distribute the load among the running instances.

• Using Oracle HTTP servers in reverse proxy mode. In this mechanism, Oracle HTTP Server can be used in front of origin servers simply configured as a reverse proxy—that is, proxy for content servers. This mechanism relieves the origin server load by taking advantage of the caching features of the proxy server.

In addition, Oracle9iAS offers techniques to improve the performance of servlets, EJBs, and J2EE components delivering dynamic content. J2EE components rely on HTTP for communication among Web clients and servers, and RMI-IIOP for communication among objects requesting service from each other in a distributed computing environment. In Oracle9iAS, different components work together to intelligently route HTTP and IIOP requests to nodes, thereby providing smooth response times and no single point of failover.

As a result, when an HTTP request arrives, the load-balancing device redistributes the load over Web caches that sit in front of the application server farm. Oracle9iAS Web Cache distributes the HTTP requests according to the relative capacity of each application server, which is configurable. If one of the application servers in the farm were to fail, Web Cache automatically redistributes the load among the remaining servers. Oracle9iAS Web Cache reduces application server load not only on Oracle9iAS, but on other application servers too.

Oracle HTTP Server load balances servlet processes that use the Apache JServ servlet engine. Several JServ processes can serve single or multiple instances of Oracle HTTP Server. This is done using a weighted load-balancing algorithm that can be configured, depending upon the load-handling capability of the target machines.

Oracle9iAS listener/dispatcher architecture provides a fault-tolerant and resilient environment, without a single point of failure. With this architecture, each physical machine has a listener on a designated port and a number of dispatchers to service J2EE container requests. The bridge in this paradigm is that each dispatcher registers itself with any number of nodes in the application server farm. Thus, if a particular node is no longer able to service requests, the listener will send incoming requests to another dispatcher on another node. It is important that an application server redirects both HTTP and IIOP requests intelligently for the purpose of load balancing. Redirection is essential to load balance at a protocol level. However, there is no concept of “redirection” in HTTP—but there is one for IIOP. Oracle leverages its listener/dispatcher architecture with Apache modules to provide HTTP redirection. For example, mod_ose load balances servlet requests across nodes by redirecting HTTP requests.

Oracle9iAS provides mechanisms to load-balance incoming requests IIOP or other network formats in multithreaded server mode. This has great benefits to enterprise components residing on multiple nodes. The listener process has the ability to load-balance across these nodes using IIOP redirection. This is possible because of the listener's ability to inspect IIOP headers for session IDs and redirect to the appropriate node. Incoming IIOP connections are redirected to dispatchers on the node with least load. The load is computed based on number of parameters, including CPU utilization, number of sessions in progress, and so on. With load balancing, you can split the load across multiple servers. The Listener process within Oracle9iAS performs load balancing by distributing EJB lookup across multiple application servers. Services that are located in a number of places can be grouped together by specifying a service name in the URL. Listener handles HTTP connections by transferring such requests to configured dispatchers on a node.