89 Configuring a Session

This chapter describes how to configure TopLink sessions.

This chapter includes the following sections:

Table 89-1 lists the types of TopLink sessions that you can configure and provides a cross-reference to the type-specific chapter that lists the configurable options supported by that type.

Table 89-1 Configuring TopLink Sessions

If you are creating... See...

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Chapter 91, "Configuring Server Sessions"

Unit of work sessions (see Section 87.4, "Unit of Work Sessions")

Chapter 113, "Introduction to TopLink Transactions"

Isolated client sessions (see Section 87.5, "Isolated Client Sessions")

Chapter 92, "Configuring Exclusive Isolated Client Sessions for Virtual Private Database"

Historical sessions (see Section 87.6, "Historical Sessions")

Chapter 93, "Configuring Historical Sessions"

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Chapter 94, "Configuring Session Broker and Client Sessions"

Database sessions (see Section 87.8, "Database Sessions")

Chapter 95, "Configuring Database Sessions"

Table 89-2 lists the configurable options shared by two or more TopLink sessions types.

For more information, see the following:

89.1 Configuring Common Session Options

Table 89-2 lists the configurable options shared by two or more TopLink session types. In addition to the configurable options described here, you must also configure the options described for the specific Session Types, as shown in Table 89-1

Table 89-2 Configurable Options for Session

Option to Configure Oracle JDeveloper
 TopLink Workbench Java

Primary mapping project (see Section 89.2, "Configuring a Primary Mapping Project")

 Supported Supported Supported

Session login (see Section 89.3, "Configuring a Session Login")

 Supported Supported Supported

Logging (see Section 89.4, "Configuring Logging")

 Supported Supported Supported

Multiple mapping projects (see Section 89.5, "Configuring Multiple Mapping Projects")

 Supported Supported Supported

Performance profiler (see Section 89.6, "Configuring a Performance Profiler")

 Supported Supported Supported

Exception handler (see Section 89.7, "Configuring an Exception Handler")

 Supported Supported Supported

Session customizer class (see Section 89.8, "Configuring a Session Customizer Class")

 Supported Supported Supported

Server platform (see Section 89.9, "Configuring the Server Platform")

 Supported Supported Supported

Session event listener (see Section 89.10, "Configuring Session Event Listeners")

 Supported Supported Supported

Coordinated cache (see Section 103, "Configuring a Coordinated Cache")

 Supported Supported Supported

Integrity checker (see Section 89.11, "Configuring the Integrity Checker")

 Unsupported Unsupported Supported

Connection policy (see Section 89.12, "Configuring Connection Policy")

 Supported Supported Supported

Named queries (see Section 89.13, "Configuring Named Queries at the Session Level")

 Unsupported Unsupported Supported

89.2 Configuring a Primary Mapping Project

The mapping project contains your TopLink mapping metadata (see Chapter 15, "Introduction to Projects"), including descriptors and mappings. Each session is associated with at least one project so that the session can register the descriptors.

Table 89-3 summarizes which sessions support a primary mapping project configuration.

Table 89-3 Session Support for Primary Mapping Project

Session How to Use Oracle JDeveloper How to Configure a Primary Mapping Project Using TopLink Workbench
 How to Configure a Primary Mapping Project Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

Using Oracle JDeveloper TopLink Editor or TopLink Workbench, you can export your mapping metadata as either a deployment XML file or as a Java class. Consequently, in a session, you can specify the mapping project as an XML file or as a Java class.

Oracle recommends that you export your mapping metadata from Oracle JDeveloper as a deployment XML file (see Section 116.3, "Exporting Project Information").

If you export your mapping metadata as a Java class, you must compile it and add it to the session configuration classpath (see Section 88.3, "Configuring a Sessions Configuration") before adding it to a session.

Note:

When specifying the mapping project using XML, you can specify the Java resource path. In most applications, the sessions.xml and project.xml files are deployed inside the JAR file, and the project XML path is specified as a Java resource path.

When specifying the Java resource path, ensure that you are using the forward slash character ( / ) for directories, not the back slash ( \ ). For example, com/myapp/mypersistence/my-project.xml, or META-INF/my-project.xml.

See Section 89.5, "Configuring Multiple Mapping Projects" for information on configuring additional TopLink projects for the session.

89.2.1 How to Configure a Primary Mapping Project Using TopLink Workbench

To specify the primary TopLink project metadata for your session, use this procedure:

  1. Select a server or database session in the Navigator. Its properties appear in the Editor.

  2. Click the General tab. The General tab appears.

  3. Click the Project subtab. The Project subtab appears.

    Figure 89-1 General Tab, Project Subtab, Primary Project Option

    Description of Figure 89-1 follows
    Description of "Figure 89-1 General Tab, Project Subtab, Primary Project Option"

  4. Select the following options:

    Figure 89-2 Edit Primary Project Dialog Box

    Description of Figure 89-2 follows
    Description of "Figure 89-2 Edit Primary Project Dialog Box"

Use this information to enter date in each field of the Edit Primary Project dialog box:

Field Description
XML Select XML to add a mapping project as a deployment XML file. Click Browse to select the file.
Class Select Class to add a mapping project as a compiled Java class file. Click Browse to select the file.

89.2.2 How to Configure a Primary Mapping Project Using Java

Using Java, you can register descriptors with a session using the following API:

  • Project API–Read your project.xml file (or instantiate your project class) and create your session using Project method createServerSession or createDatabaseSession.

  • Session API–Add a descriptor or set of descriptors to a session using the DatabaseSession API that Table 89-4 lists. Descriptors should be registered before login, but independent sets of descriptors can be added after login.

Table 89-4 DatabaseSession API for Registering Descriptors

Session Method Description

addDescriptors(Project)

Add to the session all the descriptors owned by the passed in Project.

addDescriptors(Vector)

Add to the session all the descriptors in the passed in Vector.

addDescriptor(Descriptor)

Add an individual descriptor to the session.

89.3 Configuring a Session Login

A session login encapsulates details of data source access for any session that persists to a data source. The session login overrides any other login configuration.

Table 89-5 summarizes which sessions support session login configuration.

Table 89-5 Session Support for Session Login

Session Session Login

Server and Client Sessions

Supported.

Session Broker and Client Sessions

Supported.

Database Sessions

Supported.

The session login provides access to a variety of features, including the following:

  • Connection configuration such as whether or not to use external connection pooling.

  • Sequencing configuration (that overrides sequencing configuration made at the project level, if any).

  • Miscellaneous options specific to your chosen data source.

  • Properties (arbitrary, application-specific named values).

For more information, see the following:

89.4 Configuring Logging

Use the TopLink logging framework to record TopLink behavior to a log file or session console.

Table 89-6 summarizes which sessions support logging configuration.

Table 89-6 Session Support for Logging

Session How to Use Oracle JDeveloper How to Configure Logging Using TopLink Workbench
 How to Configure Logging Using Session API in Java
 How to Configure Logging in a Java EE Container

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Supported.

Unit of work sessions (see Section 87.4, "Unit of Work Sessions")

Supported.

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

 Unsupported

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

 Unsupported

Note:

If the session belongs to a session broker, you must specify the logging information in the session broker–not in the session itself.

By default, TopLink uses its own native logger. Alternatively, you can configure TopLink to use the java.util.logging package (see Section 89.4.5, "How to Configure a Session to use the java.util.logging Package").

For more information, see Section 87.2.6, "Logging".

89.4.1 How to Configure Logging Using TopLink Workbench

To specify the logging information for a session, use this procedure:

  1. Select a database session in the Navigator. Its properties appear in the Editor.

  2. Click the Logging tab. The Logging tab appears.

    Figure 89-3 Logging Tab

    Description of Figure 89-3 follows
    Description of "Figure 89-3 Logging Tab"

Use the following information to enter data in each field of the Logging tab to select the profiler option to use with this session:

Option Description
No Logging Select this option to specify that nothing is logged for this session.
Server Select this option to use logging capabilities of the application server to which you are deploying this application.
Java Select this option to use java.util.logging package.
Standard Select this option to use the TopLink logging framework.

When selected, you can optionally configure the following options.
    Logging Level Define the amount of logging information to record (in ascending order of information):

  • Config–Log only login, JDBC connection, and database information.

  • Info (default)–Log the login/logout per sever session, with user name. After acquiring the session, detailed information is logged.

  • Warning–Log exceptions that do not force TopLink to stop, including all exceptions not logged with Severe level. This does not include a stack trace.

  • Severe –Log exceptions indicating TopLink cannot continue, and any exceptions generated during login. This includes a stack trace.

  • Fine–Log SQL (including thread information).

  • Finer–Similar to warning. Includes stack trace.

  • Finest–Includes additional low-level information.

  • All–Log everything.
    Console Select this option to display logging information to the standard console output.
    File Select this option to record logging information in a file. Click Browse to specify the name and location of the log file.
Options Select this option to override additional logging option defaults for Java and Standard logging only.
    Log Exception Stack Trace Select this option to include the stack trace with any exception written to the log.

Default: For SEVERE messages, log stack trace. For WARNING messages, only log stack trace at log level FINER or lower.
    Print Connection Select this option to include the connection identifier in any connection related log messages.

Default: Enabled for all message and log levels.
    Print Date Select this option to include the date and time at which the log message was generated.

Default: Enabled for all message and log levels.
    Print Session Select this option to include the session name in any session related log messages.

Default: Enabled for all message and log levels.
    Print Thread Select this option to include the thread name in any thread related log messages.

Default: Log only at log level FINER or lower.

89.4.2 How to Configure Logging Using Session API in Java

If you use TopLink native logging (the default), then at run time, you can configure logging options using oracle.toplink.sessions.Session logging API.

The Session interface defines the following logging methods:

  • setSessionLog–specify the type of logging to use (any implementor of oracle.toplink.logging.SessionLog)

  • dontLogMessages–disable logging

  • setLog–specify the java.io.Writer to which the session logs messages

  • setLogLevel– specify the level at which the session logs using oracle.toplink.logging.SessionLog constants:

    • OFF

    • SEVERE

    • WARNING

    • INFO

    • CONFIG

    • FINE

    • FINER

    • FINEST

    • ALL

Example 89-1 illustrates how to configure a session to use java.util.logging package.

Example 89-1 Configuring a Session to Use java.util.logging

session.setSessionLog(new JavaLog());

Example 89-2 illustrates how to configure a session to use the server log that OC4J provides. For more information about server logging, see Section 87.2.6.1.3, "Server Logging".

Example 89-2 Configuring a Session to Use Application Server Logging

session.setSessionLog(new OjdlLog());

Example 89-3 illustrates how to configure a session to log to a java.io.Writer:

Example 89-3 Configuring a Session to Log to a java.io.Writer

session.setLog(myWriter);

89.4.3 How to Configure Logging Using Oracle Enterprise Manager

When you deploy a EclipseLink JPA or TopLink CMP application to Oracle Application Server, you can use Oracle Enterprise Manager to configure TopLink logging.

For more information, see the following:

89.4.4 How to Configure Logging in a Java EE Container

For a TopLink-enabled CMP application deployed to an application server, you do not configure a session directly. In this case, you specify the type of logging by configuring system property toplink.log.destination with one of the following values:

  • fully qualified file specification (for example, C:\logs\toplink.log)–use TopLink native logging to write log messages to the specified file.

  • JAVA–use java.util.logging package to write log messages to any destination you configure in the <JRE_HOME>/lib/logging.properties file.

  • SERVER–use server logging to write log messages to the application server's log file (there is no separate TopLink log file in this case).

  • SYSOUT–write log messages to System.out.

You can set the log level for TopLink standard (default) logging through the toplink.log.level system property.

To configure other logging options, use a customization-class (see Section 9.9.1.1, "Configuring pm-properties").

89.4.5 How to Configure a Session to use the java.util.logging Package

If you use java.util.logging package, then you configure logging options in the <JRE_HOME>/lib/logging.properties file. Messages are written to zero or multiple destinations based on this configuration file.

If you configure a session to use java.util.logging package, consider the following:

89.4.5.1 logging.properties

Configure the logging.properties file as Example 89-4 illustrates:

Example 89-4 java.util.logging Configuration in logging.properties

handlers = java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level = CONFIG
java.util.logging.ConsoleHandler.formatter = oracle.toplink.logging.TopLinkSimpleFormatter
oracle.toplink.LoggingSession.connection.level = CONFIG

For information about the types of formatters available, see Section 89.4.5.2, "Formatters".

89.4.5.2 Formatters

TopLink provides two formatters: TopLinkSimpleFormatter and TopLinkXMLFormatter. They override the corresponding java.util.logging formatters and always log session and connection info when available. They also log thread and exception stack trace information at certain levels as specified by the logging level.

89.4.5.3 Namespace

Namespace is supported for java.util.logging. Table 89-7 lists the static constants defined in oracle.toplink.sessions.SessionLog for TopLink components and the corresponding strings in logging.properties.

Table 89-7 Logging Property FIle Names

SessionLog logging.properites

Not Applicable

oracle.toplink

Not Applicable

oracle.toplink.<sessionname>

SQL

oracle.toplink.<sessionname>.sql

TRANSACTION

oracle.toplink.<sessionname>.transaction

EVENT

oracle.toplink.<sessionname>.event

CONNECTION

oracle.toplink.<sessionname>.connection

QUERY

oracle.toplink.<sessionname>.query

CACHE

oracle.toplink.<sessionname>.cache

PROPAGATION

oracle.toplink.<sessionname>.propagation

SEQUENCING

oracle.toplink.<sessionname>.sequencing

EJB

oracle.toplink.<sessionname>.ejb

DMS

oracle.toplink.<sessionname>.dms

EJB_OR_METADATA

oracle.toplink.<sessionname>.ejb_or_metadata

WEAVER

oracle.toplink.<sessionname>.weaver

PROPERTIES

oracle.toplink.<sessionname>.properties

SERVER

oracle.toplink.<sessionname>.server

In the logging.properties names listed in Table 89-7, note that <sessionname> is the name of the session that the application is running in. For example, if the name of the session is MyApplication, then you would use oracle.toplink.MyApplication.sql for the SQL logging property.

An application can also define its own namespace and write to it through the logging API, as long as the logger for that namespace is defined in the logging configuration. Otherwise messages are written to the parent logger, oracle.toplink.<sessionname>.

89.5 Configuring Multiple Mapping Projects

Each session is associated with at least one mapping project (see Section 89.2, "Configuring a Primary Mapping Project"). You can include additional TopLink mapping projects for a session.

Table 89-8 summarizes which sessions support additional mapping project configuration.

Table 89-8 Session Support for Additional Mapping Project

Session How to Use Oracle JDeveloper How to Configure Multiple Mapping Projects Using TopLink Workbench
 How to Configure Multiple Mapping Projects Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

  

Supported.

Supported.

Session broker and client sessions (see Chapter 87, "Session Broker and Client Sessions")

  

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

  

Supported.

Supported.

89.5.1 How to Configure Multiple Mapping Projects Using TopLink Workbench

To specify additional TopLink projects for your session, use this procedure:

  1. Select a server or database session in the Navigator. Its properties appear in the Editor.

  2. Click the General tab. The General tab appears.

  3. Click the Project subtab. The Project subtab appears.

    Figure 89-4 General Tab, Project Subtab, Multiple Projects Options

    Description of Figure 89-4 follows
    Description of "Figure 89-4 General Tab, Project Subtab, Multiple Projects Options"

  4. Select Multiple Projects option. The Multiple Projects subtab appears.

  5. Click the Multiple Projects subtab.

  6. Figure 89-5 General Tab, Multiple Projects Subtab

    Description of Figure 89-5 follows
    Description of "Figure 89-5 General Tab, Multiple Projects Subtab"

To add an additional mapping project to this session, click Add. For more information, see Section 89.2, "Configuring a Primary Mapping Project".

To remove TopLink mapping projects, select the project file and click Remove.

89.5.2 How to Configure Multiple Mapping Projects Using Java

Using Java, you can register descriptors from more than one project with a session using the DatabaseSession API that Table 89-9 lists. You can register descriptors before login, but you can add independent sets of descriptors after login.

Table 89-9 DatabaseSession API for Registering Descriptors

Session Method Description

addDescriptors(Project)

Add additional descriptor to the session in the form of a project.

addDescriptors(Vector)

Add a vector of individual descriptor files to the session in the form of a project.

addDescriptor(Descriptor)

Add individual descriptor to the session.

89.6 Configuring a Performance Profiler

To successfully improve the performance of a TopLink application, you must measure performance before and after each optimization. TopLink provides a variety of built-in performance measuring features (known as profilers) that you can configure at the session level.

Table 89-10 summarizes which sessions support performance profiler configuration.

Table 89-10 Session Support for Performance Profiler Configuration

Session How to Use Oracle JDeveloper How to Configure a Performance Profiler Using TopLink Workbench
 How to Configure a Performance Profiler Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

TopLink provides the following profilers:

89.6.1 How to Configure a Performance Profiler Using TopLink Workbench

To specify the type of profiler in a session, use this procedure:

  1. Select a session in the Navigator. Its properties appear in the Editor.

  2. Click the Options tab. The Options tab appears.

    Figure 89-6 Options Tab, Profiler Options

    Description of Figure 89-6 follows
    Description of "Figure 89-6 Options Tab, Profiler Options"

Use the following information to select the profiler option to use with this session:

Option Description
No Profiler Disable all profiling.
DMS Enable Oracle Dynamic Monitoring (DMS) profiling. For more information, see the following:
Standard (TopLink) Enable TopLink profiling. For more information, see the following:

89.6.2 How to Configure a Performance Profiler Using Java

You can use Java to configure a session with a profiler using Session method setProfiler, as Example 89-5 shows.

Example 89-5 Configuring a Session with a TopLink Profiler

session.setProfiler(new PerformanceProfiler());

To end a profiling session, use Session method clearProfiler.

89.7 Configuring an Exception Handler

You can associate a single exception handling class with each session. This class must implement the oracle.toplink.exceptions.ExceptionHandler interface.

Table 89-11 summarizes which sessions support exception handler configuration.

Table 89-11 Session Support for Exception Handler Configuration

Session How to Use Oracle JDeveloper How to Configure an Exception Handler Using TopLink Workbench
 How to Configure an Exception Handler Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

For an example exception handler implementation, see Section 89.7.2, "How to Configure an Exception Handler Using Java".

For more information, see Section 87.2.9, "Exception Handlers".

89.7.1 How to Configure an Exception Handler Using TopLink Workbench

To specify the exception handler class in a session, use this procedure:

  1. Select a session in the Navigator. Its properties appear in the Editor.

  2. Click the Options tab. The Options tab appears.

    Figure 89-7 Options Tab, Exception Handler Field

    Description of Figure 89-7 follows
    Description of "Figure 89-7 Options Tab, Exception Handler Field"

  3. Complete the Exception Handler field.

Click Browse and select the exception handler class for this session.

89.7.2 How to Configure an Exception Handler Using Java

Example 89-6 shows an example exception handler implementation. In this implementation, the exception handler always tries to reestablish the connection if it has been reset by peer, but only retries a query if it is an instance of ReadQuery. Note that this exception handler either returns the result of the reexecuted ReadQuery or throws an exception.

Example 89-6 Implementing an Exception Handler

session.setExceptionHandler(
  new ExceptionHandler() {
    public Object handleException(RuntimeException exception) {
      if (exception instanceof DatabaseException) {
        DatabaseException dbex = (DatabaseException) exception;
        if ((dbex.getInternalException() instanceof SQLException) && 
           (((SQLException) dbex.getInternalException()).getErrorCode() == MyDriver.CONNECTION_RESET_BY_PEER)) {
           dbex.getAccessor().reestablishConnection(dbex.getSession());
           if (dbex.getQuery() instanceof ReadQuery) {
             return dbex.getSession().executeQuery(dbex.getQuery(), dbex.getQuery().getTranslationRow());
           }
           throw exception;
        }
      }
      throw exception;
    }
  }
);

Note:

Unhandled exceptions must be rethrown by the exception handler code.

89.8 Configuring a Session Customizer Class

A session customizer class is a Java class that implements the oracle.toplink.tools.sessionconfiguration.SessionCustomizer interface and provides a default (zero-argument) constructor. You can use a session customizer to customize a session at run time on a loaded session before login occurs, similar to how you can use an amendment method to customize a descriptor (see Section 119.35, "Configuring Amendment Methods"). For example, you can use a session customizer class to define and register session event listeners with the session event manager (see Section 89.10, "Configuring Session Event Listeners").

Table 89-12 summarizes which sessions support customizer class configuration.

Table 89-12 Session Support for Customizer Class Configuration

Session How to Use Oracle JDeveloper How to Configure Customizer Class Using TopLink Workbench
 How to Use Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

For more information, see Section 87.2.3, "Session Customization".

89.8.1 How to Configure Customizer Class Using TopLink Workbench

To specify the session customizer class in a session, use this procedure:

  1. Select a session in the Navigator. Its properties appear in the Editor.

  2. Click the Options tab. The Options tab appears.

    Figure 89-8 Options Tab, Session Customizer Class Field

    Description of Figure 89-8 follows
    Description of "Figure 89-8 Options Tab, Session Customizer Class Field"

Click Browse and select the customizer class for this session.

89.8.2 How to Configure Customizer Class Using Java

When using Java, create a customize class that implements the oracle.toplink.tools.sessionconfiguration.SessionCustomizer interface. Example 89-7 illustrates the creation of the session customizer. The customize method contains the configuration of the Login owned by the Session with the appropriate transaction isolation.

Example 89-7 Creating a SessionCustomizer Class

import oracle.toplink.tools.sessionconfiguration.SessionCustomizer;
import oracle.toplink.sessions.Session;
import oracle.toplink.sessions.DatabaseLogin;

public class EmployeeSessionCustomizer implements SessionCustomizer {

    public void customize(Sesssion session) {
        DatabaseLogin login = (DatabaseLogin)session.getDatasourceLogin();
        login.setTransactionIsolation(DatabaseLogin.TRANSACTION_READ_UNCOMMITTED);
    }
}

89.9 Configuring the Server Platform

The TopLink server platform defines how a session integrates with a Java EE server including the following:

  • Run-time services: Enables the deployment of a Java Management Extensions (JMX) MBean that allows monitoring of the TopLink session.

  • External transaction controller: Integrates the TopLink session with the server's Java Transaction API (JTA) service. This should always be used when using EJB or JTA transactions. You configure TopLink to integrate with the container's external transaction service by specifying a TopLink external transaction controller. For more information on external transaction services, see Section 113.1.2, "Unit of Work Transaction Demarcation".

Table 89-8 summarizes which sessions support a server platform.

Table 89-13 Session Support for Server Platform

Session How to Use Oracle JDeveloper How to Configure the Server Platform Using TopLink Workbench
 How to Configure the Server Platform Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

If the primary mapping project that you associate with a session has a persistence type of bean-managed persistence (BMP) or Java objects, you may configure a server platform using Oracle JDeveloper or TopLink Workbench. For more information on primary mapping project, see Section 89.2, "Configuring a Primary Mapping Project".

If the primary mapping project you associate with a session has a persistence type of container-managed persistence (CMP), by default, the TopLink runtime automatically configures a server platform to accommodate the application server on which it is deployed.

89.9.1 How to Configure the Server Platform Using TopLink Workbench

To specify the server platform options for a session, use this procedure:

  1. Select a session in the Navigator. Its properties appear in the Editor.

  2. Click the General tab. The General tab appears.

  3. Click the Server Platform subtab. The Server Platform subtab appears.

    Figure 89-9 General Tab, Server Platform Subtab

    Description of Figure 89-9 follows
    Description of "Figure 89-9 General Tab, Server Platform Subtab"

Use the following information to enter data in each field of the Server Platform subtab:

Field Description
Server Platform Check this field if you intend to deploy your application to a Java EE application server.

If you check this field, you must configure the target application server by selecting a Platform.
Platform Select the Java EE application server to which you will deploy your application.

TopLink supports the following Java EE application servers:

  • WebLogic 10.n

  • WebLogic 9.n

  • OC4J 11.1.1

  • OC4J 10.1.3.n

  • SunAS 9

  • WebSphere 6.1

  • Custom

For detailed information about supported application server versions and configuration requirements, see Chapter 8, "Integrating TopLink with an Application Server".

Select Custom if you have created your own oracle.toplink.platform.server.ServerPlatform class to use an application server not currently supported by TopLink or to override an existing ServerPlatform. If you select Custom, you must specify your custom ServerPlatform class by selecting a Server Platform Class.

The server platform you select overrides the default server platform set at the sessions configuration level (see Section 88.2, "Creating a Sessions Configuration").
Enable Runtime Services Check this field to configure the TopLink runtime to enable the deployment of a JMX MBean that allows monitoring of the TopLink session.

To use this feature, you must enable DMS data collection. For more information, see Section 12.4.1, "How to Configure the Oracle DMS Profiler".
Enable External Transaction Controller (JTA) Check this field if you intend to integrate your application with an external transaction controller. For more information, see Section 113.1.2, "Unit of Work Transaction Demarcation".

If you configure Platform for a Java EE application server that TopLink supports, the TopLink runtime will automatically select the appropriate external transaction controller class.

If you configure Platform as Custom, you must specify an external transaction controller class by selecting an External Transaction Controller.
Server Platform Class This option is only available if you configure Platform as Custom.

Click Browse to select your custom ServerPlatform class.
Transaction Controller Class (JTA) This option is only available if you configure Platform as Custom.

If you checked Enable External Transaction Controller (JTA), click Browse to select the transaction controller class that corresponds with your custom ServerPlatform class.

89.9.2 How to Configure the Server Platform Using Java

When using Java, you must pass the session in a server platform constructor. Example 89-8 illustrates using a session customizer (see Section 13.4, "Using the Session Customizer Class") to configure a session with a server platform from the oracle.toplink.platform.server package.

Example 89-8 Configuring a Session with a Server Platform

import oracle.toplink.tools.sessionconfiguration.SessionCustomizer; 
...
public class MySessionCustomizer implements SessionCustomizer {
   public void customize (Session session) {
      Server server = (Server)session;
      server.setServerPlatform(new WebLogic_10_Platform(DatabaseSession)server)):
   }
}

89.10 Configuring Session Event Listeners

As you perform persistence operations with a session, the session produces various events (see Section 87.2.5.1, "Session Event Manager Events") that the TopLink runtime uses to coordinate its various components. You can configure a session with one or more session event listeners (see Section 87.2.5.2, "Session Event Listeners") to customize session behavior and debug session operations. For example, session event listeners play an important role in the configuration of isolated sessions (see Chapter 92, "Configuring Exclusive Isolated Client Sessions for Virtual Private Database").

Table 89-14 summarizes which sessions support event listeners.

Table 89-14 Session Support for Event LIsteners

Session How to Use Oracle JDeveloper How to Configure Session Event Listeners Using TopLink Workbench
 How to Configure Session Event Listeners Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

Supported.

Supported.

Supported.

Database sessions (see Section 87.8, "Database Sessions")

Supported.

Supported.

Supported.

89.10.1 How to Configure Session Event Listeners Using TopLink Workbench

Session Event Listeners

To specify the event listener class in a session, use this procedure:

  1. Select a session in the Navigator. Its properties appear in the Editor.

  2. Click the Options tab. The Options tab appears.

    Figure 89-10 Options Tab, Event Listeners field

    Description of Figure 89-10 follows
    Description of "Figure 89-10 Options Tab, Event Listeners field"

To add a new event listener, click Add, then select the event listener class for this session.

To remove an existing event listener, select the Event Listener and click Remove.

89.10.2 How to Configure Session Event Listeners Using Java

Example 89-9 illustrates how to use Java to register a session event listener with a session. TopLink provides a SessionEventAdapter to simplify creating a SessionEventListener. The SessionEventAdapter provides a default implementation of all the methods of the SessionEventListener interface. You need only override the specific methods of interest. Typically, you would define session event listeners in a session customizer class (see Section 89.8, "Configuring a Session Customizer Class").

Example 89-9 Using the Session Event Adapter to Create a Session Event Listener

...
SessionEventAdapter myEventListener = new SessionEventAdapter() {
    // Listen for PostCommitUnitOfWork events
    public void postCommitUnitOfWork(SessionEvent event) {
        // Call the handler routine
        unitOfWorkCommitted();
    }
};
mySession.getEventManager().addListener(myEventListener);
...

For information on how to add logging to your listeners, see Section 87.2.6, "Logging".

89.11 Configuring the Integrity Checker

When you log into a session, TopLink initializes and validates the descriptors you registered with it. By configuring the integrity checker, you can customize this validation process to do the following:

Table 89-15 summarizes which sessions support descriptor integrity checking configuration.

Table 89-15 Session Support for Checking Descriptor Integrity

Session How to Use Oracle JDeveloper How to Use TopLink Workbench How to Configure the Integrity Checker Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

 Unsupported Unsupported

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

 Unsupported Unsupported

Supported.

Database sessions (see Section 87.8, "Database Sessions")

 Unsupported Unsupported

Supported.

Check Database

The IntegrityChecker method setShouldCheckDatabase specifies whether or not the integrity checker should verify the descriptor's metadata against the database metadata. This will report any errors due to missing or incorrect table or fields specified in the descriptors. This is turned off by default as it adds a significant overhead to connecting a session.

Catch All Exceptions

By default, the integrity checker catches all exceptions that occur during initialization, and throws a single exception at the end of initialization reporting all of the errors detected. If you only want the first exception encountered, you can disable this feature using IntegrityChecker method setShouldCatchExceptions(false).

Catch Instantiation Policy Exceptions

By default, the integrity checker tests the default or configured constructor for each descriptor initialized in the session. To disable this feature, use IntegrityChecker method setShouldCheckInstantiationPolicy(false).

89.11.1 How to Configure the Integrity Checker Using Java

As Example 89-10 shows, you can configure the integrity checker validation process.

Example 89-10 Configuring the Integrity Checker

session.getIntegrityChecker().setShouldCheckDatabase(true);
session.getIntegrityChecker().setShouldCatchExceptions(false);
session.getIntegrityChecker().setShouldCheckInstantiationPolicy(false);
session.login();

89.12 Configuring Connection Policy

Using a connection policy, you can control how a TopLink session acquires and uses read and write connections, including the following:

Table 89-15 summarizes which sessions support connection policy configuration.

Table 89-16 Session Support for Connection Policy

Session How to Use Oracle JDeveloper How to Configure Connection Policy Using TopLink Workbench
 How to Configure Connection Policy Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

Supported.

Supported.

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

 Unsupported Unsupported Unsupported

Database sessions (see Section 87.8, "Database Sessions")

 Unsupported Unsupported Unsupported

Exclusive Write Connections

An exclusive connection is one that TopLink allocates to a client session for reading (of isolated data) and writing for the duration of the client session's life cycle.

By default, exclusive connections are not used and a client session uses the server session's read connection pool for all non-pessimistic read queries. A connection is obtained from the read connection pool for each read query execution and released back to the pool after the query is executed. A connection is only obtained from the write connection pool for the unit of work commit operation, or, potentially, earlier if data modify queries, or read queries using pessimistic locking are used. The connection will be release back to the write connection pool after the unit of work is committed or released. Exclusive connections are provided for use with database read security or Virtual Private Database (VPD) support. When using an exclusive connection, you will obtain it from the server session's write connection pool. When you acquire the client, the exclusive connection will be used for read queries to isolated classes (see Section 87.5, "Isolated Client Sessions"), exclusive read queries, pessimistic read queries, and for the unit of work commit operation. The exclusive connection will only be released when the client session is released. TopLink still acquires a shared connection from the read connection pool for reading nonisolated data. If you use a JTA-managed external connection pool with exclusive connections, do not reuse a client session across JTA transaction boundaries, as the physical JTA database connection is released and acquired from the connection pool relative to the JTA transaction life cycle. A new client session, or the active unit of work, should be used for each JTA transaction. For more information, see Section 101.6, "Configuring Exclusive Read Connections".

You can also configure exclusive connections on a client-session-by-client-session basis (see Section 90.4.2, "How to Acquire a Client Session that Uses Exclusive Connections") and for named queries (see Section 119.7.1.10, "Configuring Named Query Advanced Options").

Note:

If any client session contains an exclusive connection, you must release the session (see Section 90.8, "Logging Out of a Session") when you are finished using it. Oracle does not recommend relying on the finalizer to release the connection when the session is garbage -collected. If you are using an active unit of work in a JTA transaction, you do not need to release the client session–the unit of work will release it after the JTA transaction completes.

Lazy Connection Acquisition

By default, TopLink acquires write connections lazily, when you perform the first unit of work commit operation, exclusive read query, or pessimistic read query with your client session. The write connection will also be released after each unit of work it committed or released.

Alternatively, you can configure TopLink to acquire the write connection at the time you acquire a client session, and release the connection when you release the client session.

You can also configure lazy connection acquisition on a client-session-by-client-session basis (see Section 90.4.5, "How to Acquire a Client Session that Does Not Use Lazy Connection Allocation").

89.12.1 How to Configure Connection Policy Using TopLink Workbench

To specify the connection policy in a session, use this procedure:

  1. Select a session in the Navigator. Its properties appear in the Editor.

  2. Click the Connection Policy tab. The Connection Policy tab appears.

    Figure 89-11 Connection Policy Tab

    Description of Figure 89-11 follows
    Description of "Figure 89-11 Connection Policy Tab"

89.12.2 How to Configure Connection Policy Using Java

To configure whether or not an exclusive connection is allocated to a particular isolated session, use ConnectionPolicy method setShouldUseExclusiveConnection.

To define a map of properties used to support an isolated session, use the following ConnectionPolicy methods:

  • setProperty(Object key, Object value): Adds the property value to the Map under key, overwriting the existing value if key already exists in the Map.

  • Object getProperty(Object key): Returns the value associated with key as an Object.

  • boolean hasProperties: Returns true if one or more properties exist in the Map; otherwise returns false.

The TopLink runtime passes this Map into SessionEvent events PostAcquireExclusiveConnection and PreReleaseExclusiveConnection so that your implementation can make the appropriate PL/SQL calls to the underlying database platform (see Section 92.2, "Using PostAcquireExclusiveConnection Event Handler" and Section 92.3, "Using PreReleaseExclusiveConnection Event Handler").

To configure the session to use a named connection pool, use the ConnectionPool constructor that takes a String connection pool name as an argument:

Session clientSession = server.acquireClientSession(
    new ConnectionPolicy("myConnectionPool")
);

89.13 Configuring Named Queries at the Session Level

A named query is a TopLink query that you create and store, by name, in a session for later retrieval and execution. Named queries improve application performance, because they are prepared once and they (and all their associated supporting objects) can be efficiently reused thereafter making them well-suited for frequently executed operations.

If a named query is global to a project, configure it at the session level. Alternatively, you can configure a named query at the descriptor level (see Section 119.7, "Configuring Named Queries at the Descriptor Level").

Use named queries to specify SQL, EJB QL, or TopLink Expression queries to access your data source.

Table 89-17 summarizes which sessions support named query configuration.

Table 89-17 Session Support for Named Queries

Session How to Use Oracle JDeveloper How to Use TopLink Workbench How to Configure Named Queries at the Session Level Using Java

Server and client sessions (see Section 87.3, "Server and Client Sessions")

 Unsupported Unsupported

Supported.

Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions")

 Unsupported Unsupported

Supported.

Database sessions (see Section 87.8, "Database Sessions")

 Unsupported Unsupported

Supported.

After you create a named query, you can execute it by name on the TopLink session (see Section 109.3, "Using Named Queries").

For more information about named queries, see Section 108.8, "Named Queries".

89.13.1 How to Configure Named Queries at the Session Level Using Java

You can store a query by name in a Session using Session method addQuery(String name, DatabaseQuery query).