| Oracle® TopLink Developer's Guide 10g Release 3 (10.1.3.1.0) Part Number B28218-01 |
|
|
View PDF |
| Oracle® TopLink Developer's Guide 10g Release 3 (10.1.3.1.0) Part Number B28218-01 |
|
|
View PDF |
This chapter describes how to configure TopLink sessions.
Table 74-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 74-1 Configuring TopLink Sessions
Table 74-2 lists the configurable options shared by two or more TopLink sessions types.
For more information, see the following:
Table 74-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 74-1
Table 74-2 Configurable Options for Session
| Option | Type | TopLink Workbench | Java |
|---|---|---|---|
|
"Configuring a Primary Mapping Project" |
Basic |
 |
|
|
|
Basic |
|
|
|
|
Basic |
|
|
|
"Configuring Multiple Mapping Projects" |
Advanced |
|
|
|
"Configuring a Performance Profiler" |
Advanced |
|
|
|
"Configuring an Exception Handler" |
Advanced |
|
|
|
"Configuring Customizer Class" |
Advanced |
|
|
|
"Configuring the Server Platform" |
Advanced |
|
|
|
"Configuring Session Event Listeners" |
Advanced |
|
|
|
"Configuring a Coordinated Cache" |
Advanced |
|
|
|
"Configuring the Integrity Checker" |
Advanced |
 |
|
|
"Configuring Connection Policy" |
Advanced |
|
|
|
"Configuring Named Queries at the Session Level" |
Basic |
|
|
The mapping project contains your TopLink mapping metadata (see "Understanding Projects"), including descriptors and mappings. Each session is associated with at least one project so that the session can register the descriptors.
Table 74-3 summarizes which sessions support a primary mapping project configuration.
Table 74-3 Session Support for Primary Mapping Project
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client Sessions |
|
|
|
|
|
|
Using 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 TopLink Workbench as a deployment XML file (see "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 "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, |
See "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 74-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 "Configuring Multiple Mapping Projects" for more information.
Figure 74-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 74-4 lists. Descriptors should be registered before login, but independent sets of descriptors can be added after login.
Table 74-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 74-5 summarizes which sessions support session login configuration.
Table 74-5 Session Support for Session Login
| Session | Session Login |
|---|---|
|
|
|
|
Session Broker and Client Sessions |
|
|
|
|
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 74-6 summarizes which sessions support logging configuration.
Table 74-6 Session Support for Logging
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
|
|
|
|
Session Broker and Client 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. |
For a non-CMP application, you can configure logging using TopLink Workbench (see "Using TopLink Workbench"). For a CMP application, see "Configuring Logging in a CMP Application".
For more information, see "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 |
This section describes the following:
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 74-1 illustrates how to configure a session to use java.util.logging package.
Example 74-2 illustrates how to configure a session to use the server log that OC4J provides. For more information about server logging, see "Server Logging".
Example 74-2 Configuring a Session to Use Application Server Logging
session.setSessionLog(new OjdlLog());
Example 74-3 illustrates how to configure a session to log to a java.io.Writer:
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 74-4 illustrates:
Example 74-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 "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 74-7 lists the static constants defined in oracle.toplink.logging.SessionLog for TopLink components and the corresponding strings in logging.properties.
Table 74-7 Logging Property FIle Names
| SessionLog | logging.properites |
|---|---|
|
Not Applicable |
|
|
Not Applicable |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the logging.properties names listed in Table 74-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>.
For a CMP project, 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.
The log level for TopLink standard (default) logging can be set through the toplink.log.level system property.
To configure other logging options, use a customization-class (see "Configuring pm-properties").
Each session is associated with at least one mapping project (see "Configuring a Primary Mapping Project"). You can include additional TopLink mapping projects for a session.
Table 74-8 summarizes which sessions support additional mapping project configuration.
Table 74-8 Session Support for Additional Mapping Project
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client 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 74-4 General Tab, Project Subtab, Multiple Projects Options
Select Multiple Projects option. The Multiple Projects subtab appears.
Figure 74-5 General Tab, Multiple Projects Subtab
To add an additional mapping project to this session, click Add. For more information, see "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 74-9 lists. You can register descriptors before login, but you can add independent sets of descriptors after login.
Table 74-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 74-10 summarizes which sessions support performance profiler configuration.
Table 74-10 Session Support for Performance Profiler Configuration
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client Sessions |
|
|
|
|
|
|
TopLink provides the following profilers:
TopLink profiler: logs performance statistics for every executed query in a given session (see "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 "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 74-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 74-5 shows.
Example 74-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 74-11 summarizes which sessions support exception handler configuration.
Table 74-11 Session Support for Exception Handler Configuration
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client Sessions |
|
|
|
|
|
|
For an example exception handler implementation, see "Using Java".
For more information, see "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 74-7 Options Tab, Exception Handler Field
Click Browse and select the exception handler class for this session.
Example 74-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 74-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());
}
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 "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 "Configuring Session Event Listeners").
Table 74-12 summarizes which sessions support customizer class configuration.
Table 74-12 Session Support for Customizer Class Configuration
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client Sessions |
|
|
|
|
|
|
For more information, see "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 74-8 Options Tab, Session Customizer Class Field
Click Browse and select the customizer class for this session.
The TopLink server platform defines how a session integrates with a J2EE server including the following:
Run-time services: Enables the deployment of a Java Management Extensions (JMX) MBean that allows monitoring of the TopLink session. Currently, this is only supported for OC4J.
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 "Unit of Work Transaction Demarcation".
Table 74-8 summarizes which sessions support a server platform.
Table 74-13 Session Support for Server Platform
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client 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 TopLink Workbench. For more information on primary mapping project, see "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 74-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 J2EE application server.
If you check this field, you must configure the target application server by selecting a Platform. |
| Platform | Select the J2EE application server to which you will deploy your application.
TopLink supports the following J2EE application servers:
For detailed information about supported application server versions and configuration requirements, see "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 "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. Currently, this is only supported for OC4J.
To use this feature, you must enable DMS data collection. For more information, see "Configuring 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 "Unit of Work Transaction Demarcation".
If you configure Platform for a J2EE 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 74-7 illustrates using a session event listener (see "Configuring Session Event Listeners") to configure a session with a server platform from the oracle.toplink.platform.server package.
As you perform persistence operations with a session, the session produces various events (see "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 "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 "Configuring Exclusive Isolated Client Sessions for Virtual Private Database").
Table 74-14 summarizes which sessions support event listeners.
Table 74-14 Session Support for Event LIsteners
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client 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 74-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 74-8 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 "Configuring Customizer Class").
Example 74-8 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 "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 74-15 summarizes which sessions support descriptor integrity checking configuration.
Table 74-15 Session Support for Checking Descriptor Integrity
| Session | Using TopLink Workbench | Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client 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 74-9 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 74-15 summarizes which sessions support connection policy configuration.
Table 74-16 Session Support for Connection Policy
| Session | Using TopLink Workbench |
Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client 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 "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 "Configuring Exclusive Read Connections".
You can also configure exclusive connections on a client-session-by-client-session basis (see "Acquiring a Client Session That Uses Exclusive Connections") and for named queries (see "Configuring Named Query Advanced Options").
|
Note: If any client session contains an exclusive connection, you must release the session (see "Logging Out of a Session") when you are finished using it. Relying on the finalizer to release the connection when the session is garbage collected may cause errors when dealing with JTA transactions. |
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 "Acquiring 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 "PostAcquireExclusiveConnection Event Handler" and "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 "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 74-17 summarizes which sessions support named query configuration.
Table 74-17 Session Support for Named Queries
| Session | Using TopLink Workbench | Using Java |
|---|---|---|
|
|
|
|
|
Session Broker and Client Sessions |
|
|
|
|
|
|
After you create a named query, you can execute it by name on the TopLink session (see "Using Named Queries").
For more information about named queries, see "Named Queries".
You can store a query by name in a Session using Session method addQuery(String name, DatabaseQuery query).
