In order for a Java application to be highly scalable, the Java server platform must support efficient execution of code from concurrent clients. The storage management strategy of the server is of great importance, because the Java language mandates automatic memory allocation and garbage collection. Furthermore, the Java application developer should not be unduly burdened with writing highly complex multi-threaded code, which is error prone, in order to be scalable.
The JVM in Oracle8i runs within the same address space as the database SQL engine, providing fast access to SQL data. It is closely integrated with the database, and shares the notion of a user session. A SQL session also translates to a Java user session within Oracle8i JServer.
JServer introduces the notion of session-based Java execution in which each user session effectively has its own "virtual" JVM. In other words, the programmer can assume a virtually isolated environment for each user session, where interference among multiple concurrent sessions is minimized. For example, erratic generation of garbage by user session A will not clog user sessions B or C. This unique architecture reduces synchronization and garbage collection bottlenecks that can frequently arise in a single JVM. It enables Java applications running on Oracle8i JServer to scale smoothly for increasing numbers of concurrent users without erratic degradation in performance (of course, this scaling is ultimately subject to system limitations).
Oracle8i JServer has a small memory footprint for each virtual JVM session. Although it provides the appearance of a virtual JVM for each user session, memory resources are shared between sessions as much as possible. For example, the read-only byte code of common classes is not duplicated but is shared between the different user sessions. Only state variables that are unique to a session are stored privately. Additionally, each virtual session maintains its own memory that can be garbage collected independently of other sessions. Sophisticated memory allocation techniques and "generational" garbage collection algorithms are used to maximize the performance.
The session-based programming model of JServer also alleviates the burden on the Java application developer of writing complex multi-threaded code to effectively handle resource sharing. The simpler programming paradigm supports robustness and "automatic" scalability of applications. For example, consider the initialization of a static variable in a class to a certain value. For the case of a single JVM, bad or "rogue" code in another user session could easily set a shared static variable to an undesirable value. This error scenario cannot arise in JServer, since the session-oriented virtual JVM architecture presents the appearance that each user session has its own set of static variables. Thus, the Java developer can program the application considering a single-user scenario, and without complex multi-threaded code for resource sharing.
Oracle8i JServer incorporates advanced compilation technology that converts platform-independent Java byte code to efficient native code. This optimization is done during deployment of Java code in JServer, rather than at execution time as in the usual JIT (Just-in-Time) approach, permitting more comprehensive optimization techniques to be applied.
There is a basic class called SessionTest. The class is public and defines a static variable called staticVar. This class also defines a method incrementStaticVar that adds the input value (i.e., the parameter to this method) to the static variable. There is another method getStaticVar which returns the current value of the static variable.
The code for the SessionTest class appears in the file SessionTest.java. This code was deployed on the JDK as a compiled Java class, and on the Oracle8i JServer as a stored Java program (refer to the Oracle documentation on the steps involved in this process). On JServer, the incrementStaticVar method was deployed as a stored procedure (since it does not return any value), and the getStaticVar() method was deployed as a stored function (since it returns an integer value).
Next, we define a set of platform-specific classes to demonstrate the difference in programming paradigms between the JDK and JServer.
The output of after compiling these files and executing the main method in the SessionDemo class is provided in the JDK_output.txt file. As shown in this file, the value of the static variable is 10 after construction of the first User instance, and is 30 after construction of the second User instance.
The output of the SessionDemo8i provided in the JServer_output.txt file. As shown in this file, the value of the static variable is 10 after construction of the first User instance, and is 20 after construction of the second User instance. In contrast to the JDK, the value of the static variable did not get incremented to 30. This is because each user (database) session is effectively executing in its own virtual JVM, insulating it from the effects of static variable manipulation in other sessions.
Oracle8i JServer is a comprehensive enterprise-level highly scalable Java server platform that is tightly integrated with the Oracle8i database. Both have a common notion of a user session that is effectively isolated from other concurrent user sessions, thus providing a simpler programming model. JServer presents the appearance of a dedicated virtual JVM for each user. This behavior was demonstrated through Java code executed on the JDK and on the Oracle8i JServer, and specifically for initialization of static variables.
In conclusion, JServer does not require complex multi-threaded coding for applications to be scalable. Memory management is highly optimized in this session-oriented server architecture, with independent allocation and garbage collection for each user session. Applications can be natively compiled during deployment, and once deployed, high scalability is achieved through the underlying sophisticated and efficient architecture of JServer.