Release 8.1.5
A64686-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i
Java Stored Procedures Developer's Guide Release 8.1.5 A64686-01 |
|
Oracle's Java Virtual Machine (known as the "Aurora JVM") is a complete, JDK 1.1.6-compliant Java execution environment. The Aurora JVM runs in the same process space and address space as the RDBMS kernel, sharing its memory heaps and directly accessing its relational data. This design optimizes memory use and increases throughput.
The Aurora JVM provides a run-time environment for Java objects. It fully supports Java data structures, method dispatch, exception handling, and language-level threads. It also supports all the core Java class libraries including java.lang, java.io, java.net, java.math, and java.util. Figure 1-3 shows its main components.
The Aurora JVM embeds the standard Java namespace in RDBMS schemas. This feature lets Java programs access Java objects stored in Oracle databases and application servers across the enterprise. In addition, the JVM is tightly integrated with the scalable, shared memory architecture of the RDBMS. Java programs use call, session, and object lifetimes efficiently without your intervention. So, you can scale RDBMS and middle-tier Java business objects, even when they have session-long state.
This section discusses some important differences between the Aurora JVM and typical client JVMs.
Client-based Java applications declare a single, top-level method (main()) that defines the profile of an application. Like applets, server-based applications have no such "inner loop." Instead, they are driven by logically independent clients.
Each client begins a session, calls its server-side logic modules via top-level entrypoints, and eventually ends the session. The server environment hides the managing of sessions, networks, and other shared resources from hosted Java programs.
A server cannot provide GUIs, but it can provide the logic that drives them. For example, the Aurora JVM does not supply the basic GUI components found in the JDK's Abstract Windowing Toolkit (AWT). However, all AWT Java classes are available within the server environment. So, your programs can use AWT functionality, as long as they do not attempt to materialize a GUI on the server.
The Aurora JVM is oriented to Java application deployment, not development. You can write and unit-test applications in your favorite IDE, then deploy them for execution within the RDBMS. A future release will integrate the Aurora JVM with a variety of client-side IDEs to enable remote debugging, profiling, test coverage analysis, and so on.
Java's binary compatibility allows you to work in any IDE, then upload Java class files to the server. You need not move your Java source files to the RDBMS. Instead, you can use powerful client-side IDEs to maintain Java applications that are deployed on the server.
Multi-threaded Java programs execute on the Oracle8i database server without modification. However, in a server environment, Java threads do not increase concurrency (and therefore throughput). Throughput is affected only by MTS mode, the number of OS processes used by the RDBMS, and various tuning methods.
Before porting a multi-threaded application to the server, make sure you understand how threads work with the Aurora JVM. The important differences are that on the server:
Oracle8i multi-threading refers to concurrent user sessions, not Java multi-threading. On the server, throughput is increased by supporting many concurrent user sessions. The scheduling of Java execution (of each call within a session for example) to maximize throughput is done by the RDBMS, not by Java.
This section briefly describes the main components of the Aurora JVM and some of the facilities they provide.
To store Java classes in an Oracle database, you use the command-line utility loadjava, which employs SQL CREATE JAVA statements to do its work. When invoked by the CREATE JAVA {SOURCE | CLASS | RESOURCE} statement, the library manager loads Java source, class, or resource files into the RDBMS. You never access these Java schema objects directly; only the Aurora JVM uses them.
Automated storage management is one of Java's key features. In particular, the Java run-time system requires automatic garbage collection (deallocation of memory held by unused objects). The memory manager uses memory allocation techniques tuned to object lifetimes. Objects that survive beyond call boundaries are migrated to appropriate memory areas. Also, the memory manager minimizes the footprint per session by sharing immutable object state such as class definitions and final static variables.
The Aurora JVM includes a standard JDK 1.1.6-compatible Java compiler. When invoked by the CREATE JAVA SOURCE statement, it translates Java source files into architecture-neutral instructions called bytecodes. Each bytecode consists of an opcode followed by its operands. The resulting Java class files, which conform fully to the Java standard, are submitted to the interpreter at run time.
To execute Java programs, the Aurora JVM includes a standard JDK1.1.6-compatible bytecode interpreter. The interpreter and associated Java run-time system execute standard Java class files. For high throughput, the interpreter runs on the Multi-Threaded Server, which manages sessions and schedules the execution of Java programs. The run-time system supports native methods and call-in/call-out from the host environment.
|
Note: Although your own code is interpreted, the Aurora JVM uses natively compiled versions of the core Java class libraries, object request broker (ORB), and JDBC drivers. See "JServer Accelerator". |
In response to requests from the run-time system, the Java class loader locates, loads, and initializes Java classes stored in the RDBMS. The class loader reads the class, then generates the data structures needed to execute it. Immutable data and metadata are loaded into initialize-once shared memory. As a result, less memory is required per session. The class loader attempts to resolve external references when necessary. Also, it invokes the Java compiler automatically when Java class files must be recompiled (and the source files are available).
Java class files are fully portable and conform to a well-defined format. The verifier prevents the inadvertent use of "spoofed" Java class files, which might alter program flow or violate access restrictions. Oracle security and Java security work with the verifier to protect your applications and data.
JDBC is a standard set of Java classes providing vendor-independent access to relational data. Specified by Sun Microsystems and modeled after ODBC (Open Database Connectivity) and the X/Open SQL CLI (Call Level Interface), the JDBC classes supply standard features such as simultaneous connections to several databases, transaction management, simple queries, calls to stored procedures, and streaming access to LONG column data.
Using low-level entry points, a specially tuned JDBC driver runs directly inside the RDBMS, thereby providing the fastest access to Oracle data from Java stored procedures. The server-side JDBC driver complies fully with the Sun JDBC specification. Tightly integrated with the RDBMS, it supports Oracle-specific datatypes, NLS character sets, and stored procedures. Also, the client-side and server-side JDBC APIs are the same, which makes it easy to partition applications.
SQLJ enables you to embed SQL statements in Java programs. It is more concise than JDBC and more amenable to static analysis and type checking. The SQLJ preprocessor, itself a Java program, takes as input a Java source file in which SQLJ clauses are embedded. Then, it translates the SQLJ clauses into Java class definitions that implement the specified SQL statements. The Java type system ensures that objects of those classes are called with the correct arguments.
A highly optimized SQLJ Translator runs directly inside the RDBMS, where it provides run-time access to Oracle data via the server-side JDBC driver. SQLJ forms can include queries, DML, DDL, transaction control statements, and calls to stored procedures. The client-side and server-side SQLJ APIs are the same, which makes it easy to partition applications.
The JServer Accelerator is a native-code compiler that speeds up the execution of Java programs by eliminating interpreter overhead. (See Figure 1-4.) It translates standard Java class files into specialized C source files that are processed by a platform-dependent C compiler into native libraries, which the Aurora JVM can load dynamically.
Unlike just-in-time (JIT) compilers, the JServer Accelerator is portable to all OS and hardware platforms. To speed up your applications, the Aurora JVM is supplied with natively compiled versions of the core Java class libraries, embedded ORB, and JDBC drivers.
