In a basic implementation, there is a 1:1 relationship between the com.sun.star.sdb.Connection object used by the client and physical database connection. When the Connection object is closed, the physical connection is dropped, thus the overhead of opening, initializing, and closing the physical connection is incurred for each client session. A connection pool solves this problem by maintaining a cache of physical database connections that can be reused across client sessions. Connection pooling improves performance and scalability, particularly in a three-tier environment where multiple clients can share a smaller number of physical database connections. In OpenOffice.org API, the connection pooling is part of a special service called the
ConnectionPool. This service manages newly created connections and reuses old ones when they are currently unused.
The algorithm used to manage the connection pool is implementation-specific and varies between application servers. The application server provides its clients with an implementation of the com.sun.star.sdbc.XPooledConnection interface that makes connection pooling transparent to the client. As a result, the client gets better performance and scalability. When an application is finished using a connection, it closes the logical connection using
close() at the connection interface com.sun.star.sdbc.XConnection. This closes the logical connection, but not the physical connection. Instead, the physical connection is returned to the pool so that it can be reused. Connection pooling is completely transparent to the client: A client obtains a pooled connection from the com.sun.star.sdbc.ConnectionPool service calling
getConnectionWithInfo() at its interface com.sun.star.sdbc.XDriverManager and uses it just the same way it obtains and uses a non-pooled connection.
The following sequence of steps outlines what happens when an SDBC client requests a connection from a
- The client obtains an instance of the com.sun.star.sdbc.ConnectionPool from the global service manager and calls the same methods on the
ConnectionPoolobject as on the
- The application server providing the
ConnectionPoolimplementation checks its connection pool for a suitable
PooledConnectionobject, a physical database connection, that is available. Determining the suitability of a given
PooledConnectionobject includes matching the client's user authentication information or application type, as well as using other implementation-specific criteria. The lookup method and other methods associated with managing the connection pool are specific to the application server.
- If there are no suitable
PooledConnectionobjects available, the application server creates a new physical connection and returns the
ConnectionPoolis not driver specific. It is implemented in a service called com.sun.star.sdbc.ConnectionPool.
- Regardless if the
PooledConnectionhas been retrieved from the pool or created, the application server does internal recording to indicate that the physical connection is now in use.
- The application server calls the method
PooledConnection.getConnection()to get a logical
Connectionobject. This logical
Connectionobject is a handle to a physical
PooledConnectionobject. This handle is returned by the
getConnectionWithInfo()when connection pooling is in effect.
- The logical
Connectionobject is returned to the SDBC client that uses the same Connection API as in the standard situation without a
ConnectionPool. Note that the underlying physical connection cannot be reused until the client calls the
In OpenOffice.org API, connection pooling is enabled by default and can be controlled through Tools - Options - OpenOffice.org Database . If a connection from a data source defined in OpenOffice.org API is returned, this setting applies to your connection, as well. To take advantage of the pool independently of OpenOffice.org API data sources, use the com.sun.star.sdbc.ConnectionPool instead of the
|Content on this page is licensed under the Public Documentation License (PDL).|