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).
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
- 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)
- 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.
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.