Oracle Fusion Middleware Developer's Guide for Oracle TopLink 11g Release 1 (11.1.1) Part Number B32441-03 |
|
|
View PDF |
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") |
|
Unit of work sessions (see Section 87.4, "Unit of Work Sessions") |
|
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") |
|
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") |
Table 89-2 lists the configurable options shared by two or more TopLink sessions types.
For more information, see the following:
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
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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
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, thesessions.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.
To specify the primary TopLink project metadata for your session, use this procedure:
Select a server or database session in the Navigator. Its properties appear in the Editor.
Click the General tab. The General tab appears.
Click the Project subtab. The Project subtab appears.
Figure 89-1 General Tab, Project Subtab, Primary Project Option
Select the following options:
Click Edit to define the primary project. The Edit PrimaryProject dialog box appears.
Select the Multiple Projects option to add additional projects to the session. See Section 89.5, "Configuring Multiple Mapping Projects" for more information.
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. |
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 |
---|---|
|
Add to the session all the descriptors owned by the passed in |
|
Add to the session all the descriptors in the passed in |
|
Add an individual descriptor to the session. |
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.
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:
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") |
|
|
|
|
Unit of work sessions (see Section 87.4, "Unit of Work Sessions") |
|
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
![]() |
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
![]() |
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".
To specify the logging information for a session, use this procedure:
Select a database session in the Navigator. Its properties appear in the Editor.
Click the Logging tab. The Logging tab appears.
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):
|
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 |
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 |
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-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
:
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:
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").
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:
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".
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.
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 |
|
Not Applicable |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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>
.
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") |
|
|
|
Session broker and client sessions (see Chapter 87, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
To specify additional TopLink projects for your session, use this procedure:
Select a server or database session in the Navigator. Its properties appear in the Editor.
Click the General tab. The General tab appears.
Click the Project subtab. The Project subtab appears.
Figure 89-4 General Tab, Project Subtab, Multiple Projects Options
Select Multiple Projects option. The Multiple Projects subtab appears.
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.
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 |
---|---|
|
Add additional descriptor to the session in the form of a project. |
|
Add a vector of individual descriptor files to the session in the form of a project. |
|
Add individual descriptor to the session. |
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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
TopLink provides the following profilers:
TopLink profiler: logs performance statistics for every executed query in a given session (see Section 12.3, "Measuring TopLink Performance with the TopLink Profiler")
Oracle Dynamic Monitoring System (DMS): includes DMS instrumentation in essential objects to provide efficient Web browser based monitoring of run-time data in TopLink-enabled applications (see Section 12.4, "Measuring TopLink Performance with the Oracle Dynamic Monitoring System (DMS)")
To specify the type of profiler in a session, use this procedure:
Select a session in the Navigator. Its properties appear in the Editor.
Click the Options tab. The Options tab appears.
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: |
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
.
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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
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".
To specify the exception handler class in a session, use this procedure:
Select a session in the Navigator. Its properties appear in the Editor.
Click the Options tab. The Options tab appears.
Figure 89-7 Options Tab, Exception Handler Field
Complete the Exception Handler field.
Click Browse and select the exception handler class for this session.
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.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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
For more information, see Section 87.2.3, "Session Customization".
To specify the session customizer class in a session, use this procedure:
Select a session in the Navigator. Its properties appear in the Editor.
Click the Options tab. The Options tab appears.
Figure 89-8 Options Tab, Session Customizer Class Field
Click Browse and select the customizer class for this session.
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); } }
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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
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.
To specify the server platform options for a session, use this procedure:
Select a session in the Navigator. Its properties appear in the Editor.
Click the General tab. The General tab appears.
Click the Server Platform subtab. The Server Platform subtab appears.
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:
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 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 |
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 |
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)): } }
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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
|
|
|
Database sessions (see Section 87.8, "Database Sessions") |
|
|
|
Session Event Listeners
To specify the event listener class in a session, use this procedure:
Select a session in the Navigator. Its properties appear in the Editor.
Click the Options tab. The Options tab appears.
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.
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".
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") |
![]() |
![]() |
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
![]() |
![]() |
|
Database sessions (see Section 87.8, "Database Sessions") |
![]() |
![]() |
|
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)
.
As Example 89-10 shows, you can configure the integrity checker validation process.
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") |
|
|
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
![]() |
![]() |
![]() |
Database sessions (see Section 87.8, "Database Sessions") |
![]() |
![]() |
![]() |
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").
To specify the connection policy in a session, use this procedure:
Select a session in the Navigator. Its properties appear in the Editor.
Click the Connection Policy tab. The Connection Policy tab appears.
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") );
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") |
![]() |
![]() |
|
Session broker and client sessions (see Section 87.7, "Session Broker and Client Sessions") |
![]() |
![]() |
|
Database sessions (see Section 87.8, "Database Sessions") |
![]() |
![]() |
|
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".
You can store a query by name in a Session
using Session
method addQuery(String name, DatabaseQuery query)
.