Database Connections for Threads and Commons Database Connection Pool

Date	2011/02/01
Contact(s)	Simon Pigot, Francois Prunayre, Mathieu Coudert
Last edited	2011/02/01
Status	in progress
Assigned to release	2.7.0
Resources	Available

Overview

Database connections (jeeves/src/main/java/jeeves/resources/dbms/Dbms.java) in Jeeves are handled by a ResourceManager (jeeves/src/main/java/jeeves/server/resources/ResourceManager.java) and pooled by a ResourceProvider (jeeves/src/main/java/jeeves/resources/dbms/DbmsPool.java).

A jeeves service that needs a database connection will typically open one using a call like:

Dbms dbms = (Dbms) context.getResourceManager().open(Geonet.Res.MAIN_DB);

This can be done any number of times by methods called by the service. As each Dbms object is opened the ResourceManager keeps a reference to it in an internal hashtable.

If the service completes without exception, all database connections are closed by Jeeves using context.getResourceManager().close() or if there is an exception raised context.getResourceManager().abort()

However there is a need for threads that want a database connection to obtain a connection and hold that connection open even though the service that started the thread may have closed.

This proposal will add the following calls to the ResourceManager to support threads that need a database connection in GeoNetwork/Jeeves:

• openDirect(): essentially does the same as open but does not keep a reference to the Dbms resource in the ResourceManager hashtable
• close(String name, Object resource): closes the resource from the named resource provider

In addition the proposal will add:

• a new ResourceProvider to pool database connections which uses the Apache Commons Database Connection Pool (ApacheDBCP.java) - this is a slightly more sophisticated approach to database connection pooling than the homegrown Jeeves DatabasePool.java code
• threads to support safe background database operations for: increasing popularity of metadata (eg. in metadata show), logging search statistics, indexing metadata records after the servlet has started and potentially many other operations that can be put into the background as threads to not slow down critical operations such as search
• a configurable ThreadPool that all code can access through the GeonetContext which can be used to manage thread operations eg. place limits on the number of threads that can be executed at any one time

Proposal Type

• Type: Core Change and change to coding procedures ie. use new ResourceManager calls for threads that need database connections, use ThreadPool to execute threads
• App: GeoNetwork
• Module: Kernel and services

Links

• Documents:
• Email discussions:
• Other wiki discussions:

Voting History

• Not proposed for voting yet.

---

Motivations

• provide safe database connections for threads to use
• improve database connection pooling code
• manage threads executed by GeoNetwork

Proposal

Overview gives details of proposal :-)

Backwards Compatibility Issues

New Database connection pool (ApacheDBCP.java) can be configured in config.xml, old database pool remains if someone wants to continue to use that (DbmsPool.java).

New libraries added

commons-dbcp - version 1.3 commons-pool - version 1.5.5

Risks

Everything has a certain amount of risk.....

Participants

• Simon Pigot, Francois-Xavier Prunayre, Mathieu Coudert