A recent addition to dwsDataBase is the DataBasePool static class.

As the names indicates, it facilitates pooling database connections from the script-side, while previously you had to rely on Delphi or driver-side pooling (or lack of).

DataBasePool

This is a really simple static class, with only three methods:

Acquire (name) : acquires a DataBase object from the pool of given name, or nil if the pool is empty

(name) : acquires a DataBase object from the pool of given name, or nil if the pool is empty Release (name, var db[, poolSize]) : returns a DataBase object to the pool of given name, keeping at most poolSize connections in that pool (by default 3)

(name, var db[, poolSize]) : returns a DataBase object to the pool of given name, keeping at most poolSize connections in that pool (by default 3) Cleanup([filter]) : cleanups all pools that match the name filter (by default cleanups all pools)

The pools are accessible executable-wide, thread-safe and persist across script execution.

Note that this isn’t a way to pass script DataBase instances, as this would break encapsulation. What is passed is the internal IdwsDataBase interface, not the script object.

By default a DataBase connection can only be released if it doesn’t have active transaction or opened DataSet, but you can adjust that behavior on a per-driver basis through IdwsDataBase.CanReleaseToPool.

Sample Usage

A typical usage case would be like follows

var db := DataBasePool.Acquire('MyPool'); if db = nil then db := new DataBase('SQLite', ['d:\test\db.sql3']); ... do something with the database ... DataBasePool.Release('MyPool', db);

Note that this involve pro-active behavior in the scripts, so this mechanism shouldn’t be seen as a replacement for Delphi (host application) or driver-side connection pooling, but rather as an alternative when pooling has to be managed with a finer degree of control.