Hi Tim, I’ve looked at this in the past a bit, unfortunately using it would require a more change on my part than just using the DSF with pooling. I’ll look at it again to see exactly what it would require as this pooling issue is a bit problematic.
Regarding OSGi Release 7, I have a general question for you since you’re involved in the spec process. Is there any effort going toward not using deprecated Java APIs in service specs? I have a real issue with continuing to expose deprecated APIs. I was hoping the Java 9 would go so far as hide (not export) all deprecated classes but I don’t believe this has happened. The one that comes to mind is the use of java.util.Dictionary in numerous places. I’m sure there are others. Since OSGi supports runtime versioning, it would seem that replacing Dictionary with Map would be reasonable, as well as any other deprecated APIs that are exposed. Regards, Scott From: Timothy Ward [mailto:tim.w...@paremus.com] Sent: Tuesday, November 21, 2017 4:01 AM To: user@karaf.apache.org Subject: Re: Pax JDBC DataSourceFactory connection pooling config 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 <slesc...@medline.com<mailto:slesc...@medline.com>> 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
