Skip Headers

# Configuring Connection Policy

Previous

Next

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

- Exclusive Write Connections

- Lazy Connection Acquisition

Table: Session Support for Checking Descriptor Integrity summarizes which sessions support connection policy configuration.

Session Support for Connection Policy

Session | Using TopLink Workbench | Using Java
--- | --- | ---
Server and Client Sessions |  |
Session Broker and Client Sessions |  |
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 "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").