Expresso offers a fully Java package for handling multiple concurrent database connections for handing out and returning database connections from a configurable pool of connections. This completely avoids the overhead required in establishing a new database connection, typically around 1 to 2 seconds, by reusing a collection of pre-established connections. This profoundly improves the performance for database-intensive applications where HTML pages and forms are either stored directly in a database or created on-the-fly from data or procedures stored in a database.

Expresso's connection pooling handles advanced features such as: minimum and maximum pool size, connection timeouts (with override for long running tasks), unique connection ID's and tracing, multiple database capability, even accross different database types, and the ability to use virtually anyJDBC driver without any coding required.

One of the advantages over CGI is that a Servlet can keep information between requests and share common resources. One common use of this feature is a database connection pool.

Connection pooling is a technique used to avoid the overhead of making a new database connection every time an application or server object requires access to a database. A dynamic web site often generates HTML pages from information stored in a database. Each request for a page results in a database access. The database access itself is not the bottleneck, but setting up a new connection for each request often is. A database connection pool avoids this bottleneck.

The overhead time for establishing a database connection is typically around 1 to 3 seconds. This is the time it takes to locate the database server, establish a communication channel with it, exchange information. For many web applications the database connect time can become the dominant factor in its usability, especially if it is used over the internet versus a corporate network.

Expresso is scalable; it uses a smart connection pool that holds connections open, and will open as many as it either needs or is allowed (e.g. you set a max) and hand them out to separate invocations of the same servlet when many hits arrive at once.

Jcorporate's connection pooling can work with the connection pooling provided by Enterprise JavaBean application servers, if the database objects that make up the system being implemented are created as entity EJB's. The EJB server's connection pooling then handles the pooling of connections for the entity EJB's, and the application framework's connection pool is used for all other database accesses, ensuring the entire system maintains high performance.

With security handled at the application level with the Expresso Framework and other components, it is practical to use "connection pooling" e.g. holding a number of connections open even after they have beenused in order to supply them to another process that required a connection.

It's something like holding a number of phone lines open rather than dialing every time a connection is required! This facility is automatically provided by the framework's connection pool, which any program in the system can access. In addition, database objects can request that their data be cached, for even faster read access - this is particularly helpful for objects such as the configuration values, which might be read many times without being written or changed. These two facilities ensure that the application framework scales up well.

You are not tied to any one database or application server company which means you can make changes to the software being utilized on your server as needed.

Jcorporate connection pooling implements a sophisticated database-independent type of connection pool that can handle multiple simultaneous databases and database connection pooling withsophisticated management.

While any database that can be accessed via JDBC can be used, a number of popular database engines have been tested with the system - see the system requirements documentation for recommendations of database engines to use with the system.

Database connections are expensive in terms of performance to make & re-make, so rather than making and breaking connections as required, a "pool" of database connections is maintained by the system on the server. When a servlet needs a database connection, it simply requests an available one from the pool - if none is available, a new one is created & added to the pool.

The connection pool not only grows to specified limits, but also contracts as required, closing connections that have not been used for a specified time. This avoids taking up system resources on simply holding connections that are not currently required. This also handles databases which "time-out" their connections, and prevents handing a "stale" connection to an application object. Status servlets allow the state of the connection pool to be viewed at any time, and every connection has a description that identifies it's current and last use, as well as the last time it wasaccessed.

Setup variables allow a maximum size to be set for the pool in order to limit the amount of traffic to the database if required.

Connection pooling means that a single database login & password should be allocated for access by the entire system - security is handled as described below, so this one single login/password should have full access to the database. Individual users are typically granted no access to the database at all, eliminating any security issues that might arise from allowing users access to the database directly (e.g. via ODBC).

Connections can also be "queued" - if there is a specified maximum number of connections to the database (due to limitations on either the database itself or for performance reasons), then objects requesting a connection can be "put on hold" for a few moments until another object releases its connection. The "waiting time" can also be configured to avoid unacceptable delays. In addition, background and low-priority jobs can be suspended or queued when interactive requests are waiting for connections.

Database object security means that maintaining multiple connections for multiple users is not required, further reducing the demands on the system and improving overall performance.

Most servlets in the system utilize a connection to one or more databases. These databases may be one of a number of different types, and are connected via the JDBC API and a suitable JDBC driver.

Each database context also has a database connection pool initialized for it at startup time. No connections are established immediately, but the pool grows (to a maximum size specified in the Setup values) as objects request access to the database. The connection information for the pool is stored in the expresso-config.xml file.