Hi Scott, If you’re interested in using JDBC with pooling in an OSGi environment then I really would recommend looking at the Transaction Control service. This is a new specification coming in OSGi release 7, and it provides significant extensions to the DataSourceFactory model, including pooling, managed lifecycles for your database connection usage, standard configuration properties, and transaction support (both local and XA).
The proposed reference implementation is available from Apache Aries, and implements all of the features from the specification draft. It also has a large number of tests for the various components, including local and XA JPA support (if that’s of interest). Regards, Tim > On 20 Nov 2017, at 21:47, Leschke, Scott <[email protected]> wrote: > > How does one configure the underlying connection pool when using Pax JDBC > DataSourceFactory? I’ve been using this for a while and recently discovered > it’s not behaving as I intended. I’m using Hikari as my CP, and want to > configure the following Hikari properties: > > poolName > maximumPoolSize > minimumIdle > idleTimeout > maxLifetime > > I’ve been prefixing each of these “hikari.” (which I concluded was the proper > way to do it some months ago), but it appears that Hikari is using defaults. > When I configure as follows, > > hikari.poolName = Composite Enterprise Data > hikari.maximumPoolSize = 1 > hikari.minimumIdle = 0 > hikari.idleTimeout = 28800000 > hikari.maxLifetime = 0 > > I immediately get 10 connections to the datastore, even before a connection > is actually requested to run a query (Cisco Information Server (aka, > Composite)). > This would be the default behavior if none of the above get used. I also > tried prefixing with “pool.” btw (which makes more sense to me), but get the > same behavior. > > Scott
