Server and Client Sessions

A server session manages the server side of client/server communications, providing shared resources, including a shared object cache and connection pools to a single data source.

A client session is a client-side communications mechanism that works together with the server session to provide the client/server connection. You acquire client sessions from a server session at run time as required. By default, a client session shares the session cache of its parent server session. Each client session serves one client. A client session communicates with the server session on behalf of the client application.

Each client session can have only one associated server session, but a server session can support any number of client sessions.

As Figure 75-2 illustrates, together, the client session and server session provide a three-tier architecture that you can scale easily, by adding more client sessions. A server session is the most common TopLink session type because it supports this three-tier architecture that is common in enterprise applications. Because of this scalability, Oracle recommends that you use the three-tier architecture to build your TopLink applications.

Figure 75-2 Typical TopLink Server Session with Client Session Architecture

This section explains the advantages of using server sessions and client sessions in your TopLink application, including the following:

Three-Tier Architecture Overview
Advantages of the TopLink Three-Tier Architecture

For more information, see the following:

Three-Tier Architecture Overview

In a TopLink three-tier architecture, client sessions and server sessions both reside on the server. Client applications access the TopLink application through a client session, and the client session communicates with the database using the server session.

Figure 75-3 Server Session and Client Session Usage

Description of "Figure 75-3 Server Session and Client Session Usage"

Advantages of the TopLink Three-Tier Architecture

Although the server session and the client session are two different session types, you can treat them as a single unit in most cases, because they are both required to provide three-tier functionality to the application. The server session provides the client session to client applications, and also supplies the majority of the session functionality.

This section discusses some of the advantages and general concepts associated with the TopLink three-tier design, including the following:

Shared Resources
Providing Read Access
Providing Write Access
Security and User Privileges
Concurrency
Connection Allocation

Shared Resources

The three-tier design enables multiple clients to share persistent resources. The server session provides its client sessions with a shared live object cache, read and write connection pooling, and parameterized named queries. Client sessions also share descriptor metadata.

You can use client sessions and server sessions in any application server architecture that allows for shared memory and supports multiple clients. These architectures can include HyperText Markup Language (HTML), Servlet, JavaServer Pages (JSP), Remote Method Invocation (RMI), Common Object Request Broker Architecture (CORBA), Web services, and EJB.

To support a shared object cache, client sessions must do the following:

Implement any changes to the database with the TopLink unit of work.
Share a common database login for reading (you can implement separate logins for writing).

Providing Read Access

To read objects from the database, the client must first acquire a client session from the server session. Acquiring a client session gives the client access to the session cache and the database through the server session. The server session behaves as follows:

If the object or data is in the session cache, then the server session returns the information back to the client.
If the object or data is not in the cache, then the server session reads the information from the database and stores the object in the session cache. The objects are then available for retrieval from the cache.

Because a server session processes each client request in a separate thread, this enables multiple clients to access the database connection pool concurrently.

Figure 75-4 illustrates how multiple clients read from the database using the server session.

Figure 75-4 Multiple Client Sessions Reading the Database Using the Server Session

Description of "Figure 75-4 Multiple Client Sessions Reading the Database Using the Server Session"

To read objects from the database using a client session, do the following:

Acquire a Session from the Server:

Server server = 
    (Server) SessionManager.getManager().getSession(
        sessionName, MyServerSession.class.getClassLoader()
    );
Session clientSession = (Session) server.acquireClientSession();

For more information, see "Acquiring and Using Sessions at Run Time".

Use the Session object to perform read operations (for more information, see "Understanding TopLink Queries" and "Understanding TopLink Expressions").

Note:
Oracle recommends that you do not use the Server session object directly to read objects from the database.

Providing Write Access

Because the client session disables all database modification methods, a client session cannot create, change, or delete objects directly. Instead, the client must obtain a unit of work from the client session to perform database modification methods.

To write to the database, the client acquires a client session from the server session and then acquires a unit of work within that client session. The unit of work acts as an exclusive transactional object space, and also ensures that any changes that are committed to the database also occur in the session cache.

Note:

Although client sessions are thread-safe, do not use them to write across multiple threads. Multithread write operations from the same client session can result in errors and a loss of data. For more information, see "Concurrency".

Figure 75-5 illustrates how to write to the database using a client session acquired from a server session.

Figure 75-5 Writing with Client Sessions and Server Sessions

Description of "Figure 75-5 Writing with Client Sessions and Server Sessions"

To write to the database using a unit of work, use this procedure:

Acquire a session from the server session:

Server server = 
    (Server) SessionManager.getManager().getSession(
        sessionName, MyServerSession.class.getClassLoader()
    );
Session clientSession = (Session) server.acquireClientSession();

For more information, see "Acquiring and Using Sessions at Run Time".

Acquire a UnitOfWork object from the Session object.
```
UnitOfWork uow = clientSession.acquireUnitOfWork();
```
For more information, see "Unit of Work Sessions".
Use the unit of work to perform the required updates and then commit the UnitOfWork.

For more information, see the following:

Security and User Privileges

You can define several different server sessions in your application to support users with different data access rights. For example, your application may serve a group called "Managers," who has access rights to salary information, and a group called "Employees," who do not. Because each session you define in the sessions.xml file has its own login information, you can create multiple sessions, each with its own login credentials, to meet the needs of both of these groups.

When you use internal TopLink connection pools (see "Connection Pools"), each server session provides a read connection pool and a write connection pool. All read queries use connections from the read connection pool and all queries that write changes to the data store use connections from the write connection pool. This ensures that connections for one session are kept separate from the connections used in another.

To further isolate users from one another, you can use an isolated session: a special type of client session that provides its own session cache isolated from the shared object cache of its parent server session to provide improved user-based security, or to avoid caching highly volatile data. For more information, see "Isolated Client Sessions".

Concurrency

The server session supports concurrent clients by providing each client with a dedicated thread of execution. Dedicated threads enable clients to operate asynchronously–that is, client processes execute as they are called and do not wait for other client processes to complete.

TopLink safeguards thread safety with a concurrency manager. The concurrency manager ensures that no two threads interfere with each other when performing operations such as creating new objects, executing a transaction on the database, or accessing value holders.

By default, TopLink concurrently accesses the connections in the read connection pool, however, not all JDBC drivers support concurrency. Those that do not may require a thread to have exclusive access to a JDBC connection when reading. Configure the server session to use exclusive read connection pooling in these cases.

For more information about handling concurrency issues, see "Handling Stale Data".

Connection Allocation

When you instantiate the server session, it creates a pool of data source connections. The session then manages the connection pool based on your session configuration, and shares the connections among its client sessions. When the client session releases the connection, the server session recovers the connection and makes it available to other client processes. Reusing connections reduces the number of connections required by the application and allows a server session to support a larger number of clients.

The server session provides connections to client sessions as needed. By default, the server session does not allocate a data source connection for a client session until a transaction starts (a lazy data source connection). Alternatively, you can acquire a client session that allocates a connection immediately (see "Acquiring a Client Session that Does Not Use Lazy Connection Allocation").

The server session allocates read connections from its read connection pool to all client sessions. Although a single connection supports multiple threads reading asynchronously, some JDBC drivers perform better with multiple read connections. TopLink balances the load across the read connections using a least-busy algorithm. If your application requires multiple read security levels then you must use multiple server sessions or TopLink isolated sessions (see "Isolated Client Sessions").

The server session also supports multiple write connection pools and nonpooled connections. Be default, all client sessions use the default write connection pool. However, if your application requires multiple security levels or user logins for write access, then you can use multiple write connection pools. You can configure a client session to use a specific write connection pool or nonpooled connection when it is acquired (see "Acquiring a Client Session that Uses a Named Connection Pool"). This connection is only used for writes, not reads (reads still go through the server session read connection pool).

For more information, see the following: