Database Sessions Imposed on Java Applications

In incorporating Java within the Oracle8i database, your Java application exists within the context of a database session. JServer sessions are entirely analogous to traditional Oracle sessions. Each JServer session maintains the client's Java state across calls within the session.

As demonstrated in Figure 2-1, each Java client starts up a database session as the environment for executing Java within the database. Garbage collection, session memory, and call memory exist solely for each client within its session.

Figure 2-1 Java environment within each database session

Within the context of a session, the client performs the following:

1. Connects to the database and opens a session.

2. Executes Java within the database. This is referred to as a call.

3. Continues to work within the session performing as many calls as necessary.

4. Ends the session.

Within a single session, the client has its own Java environment, which is separate from every other client's environment. It appears to the client as if a separate, individual JVM was invoked for each session, although the implementation is vastly more efficient than this seems to imply. Within a session, the Aurora JVM manages the scalability for you within the database. Every call executed from a single client is managed within its own session--separately from other clients. The Aurora JVM maximizes sharing read-only data between clients and emphasizes a minimum amount of per-session incremental footprint to maximize performance for multiple clients.

The underlying server environment hides the details associated with session, network, state, and other shared resource management issues from Java server code. Static variables are all local to the client. No client can access another client's static variables, because the memory is not available across session boundaries. Each client executes its calls within its own session, so each client's activities are separate from any other client. During a call, you can store objects in static fields of different classes, and you can expect this state to be available for your next call. The entire state of your Java program is private to you and exists for your entire session.

The Aurora JVM manages the following within the session:

• all the objects referenced by Java static variables, all the objects referred to by these objects, and so on (their transitive closure)

• garbage collection for the single client

• session memory for static variables and across call memory needs

• call memory for variables that exist within a single call

Session Lifetime

When you connect to Oracle8i, you start a database session. A session ends when one of the following events occurs:

1. The user invokes the oracle.aurora.mts.session.Session.THIS_SESSION().endSession() method.

2. The session times out. This is optional for CORBA or EJB sessions.

3. The user takes some action outside of Java code to end the database session.

Java Supported APIs

For the current Oracle8i release, we offer five Java APIs--Java stored procedures, Servlets, JavaServer Pages, CORBA distributed objects, and Enterprise JavaBeans (EJBs).

API	Lifetime
Java stored procedures	The lifetime of a Java stored procedure session is identical to the SQL session in which it is embedded. This concept is familiar to PL/SQL users. Any state represented in Java transparently persists for the lifetime of the RDBMS session, simplifying the process of writing stored procedures, triggers, and methods for Oracle Abstract Data Types. Individual invocations of Java code within a session are known as calls. For example, a call may be initiated by a SQL call.
Servlets and JavaServer Pages	Servlets and JavaServer pages provide a dynamic method for invoking Java from within HTML. Used to manage communication between HTML and Java applications stored on the resource, whether middle-tier cache or database.
CORBA and EJB	CORBA and EJB provide a more object-oriented style of message sending between clients and servers. Clients must implicitly or explicitly establish a session in the server. Every message you send on the client to a server-resident object initiates a call. Refer to the Oracle8i Enterprise JavaBeans Developer's Guide and Reference or the Oracle8i CORBA Developer's Guide and Reference books for specifics.

Note:

The concepts of call and session apply across all uses of Oracle8i.:

In addition, you can access SQL data through SQLJ or JDBC. See Chapter 3, "Invoking Java in the Database" for examples of each Java API.

---