Hadn’t really thought of the versioning issue. Like I said, not an issue I have at the moment. Thx.
From: Timothy Ward [mailto:tim.w...@paremus.com] Sent: Friday, March 03, 2017 11:39 AM To: user@karaf.apache.org Subject: Re: PAX JDBC 1.0.1 pools Hi Scott, I’m curious as to why you can’t just use osgi.jdbc.driver.name directly as I would think that’s what’s going to be in the filter for the most part. You can, and it does by default. Both properties are optional, and you must specify at least one :) If you don’t specify an aries.dsf.target.filter then it will just generate the filter “(osgi.jdbc.driver.class=<classname>)” using the value of the osgi.jdbc.driver.class property. The reason that you are allowed to specify a custom filter is to allow for further disambiguation in a system that has many DataSourceFactories (e.g. multiple versions of H2), or to find a DataSourceFactory which doesn’t declare what its driver class is. As you have noted, it isn’t commonly used. Regards, Tim On 3 Mar 2017, at 17:11, Leschke, Scott <slesc...@medline.com<mailto:slesc...@medline.com>> wrote: I apologize, I don’t believe I was clear. My question was intended to get the distinction between osgi.idle.timeout andosgi.connection.lifetime. Your answer clarified it for me anyway. I remember being confused by this when I first started using Hikari so your response took me back to that “Oh I got it” moment. One last question, mostly as a curiosity. Property aries.dsf.target.filter. I’m curious as to why you can’t just use osgi.jdbc.driver.name directly as I would think that’s what’s going to be in the filter for the most part. The filter is certainly more flexible although offhand I don’t see the use case although I suspect that’s just because it hasn’t affected me yet. As always, thanks for your help. Scott From: Timothy Ward [mailto:tim.w...@paremus.com] Sent: Friday, March 03, 2017 10:50 AM To: user@karaf.apache.org<mailto:user@karaf.apache.org> Subject: Re: PAX JDBC 1.0.1 pools Hi Scott, Well spotted! The real key is visible in the metatype definition for the jdbc provider<https://github.com/apache/aries/blob/448f6d66a727738782f7eb7498ad153d0717e1db/tx-control/tx-control-provider-jdbc-local/src/main/java/org/apache/aries/tx/control/jdbc/local/impl/Config.java#L67> and the website should say osgi.connnection.lifetime. The osgi.connection.timeout is the maximum amount of time that the pool will block for when you attempt to get a connection. If no connection is available in the pool before that timeout hits then an exception will be thrown. In vanilla Hikari this would be the connectionTimeout The osgi.connection.lifetime is the maximum amount of time that a connection will be kept open by the pool before being discarded. In a system under constant load then a connection may live a long time, being repeatedly used and returned to the pool. Some databases have a problem with very long running connections, so most pool implementations allow you to set a maximum time that a connection will be valid for, after which it will be closed and replaced by another. In vanilla Hikari this would be the maxLifetime Regards, Tim On 3 Mar 2017, at 16:28, Leschke, Scott <slesc...@medline.com<mailto:slesc...@medline.com>> wrote: From the Aries page on Txn control. What might the real name be on the second highlighted property and how would this differ from idle timeout? • osgi.connection.timeout : Defaults to 30,000 (30 seconds). The maximum time in milliseconds to block when waiting for a database connection • osgi.idle.timeout : Defaults to 180,000 (3 minutes). The time in milliseconds before an idle connection is eligible to be closed. • osgi.connection.timeout : Defaults to 10,800,000 (3 hours). The maximum time in milliseconds that a connection may remain open before being closed. Scott From: Timothy Ward [mailto:tim.w...@paremus.com] Sent: Wednesday, March 01, 2017 9:50 AM To: user@karaf.apache.org<mailto:user@karaf.apache.org> Subject: Re: PAX JDBC 1.0.1 pools Actually, the JDBC providers in Apache Aries Transaction Control do use HikariCP for their connection pooling support, it’s just abstracted by the ResourceProvider so that you don’t see it (which is surely a good thing!). Tim On 1 Mar 2017, at 15:46, Kevin Schmidt <ktschm...@gmail.com<mailto:ktschm...@gmail.com>> wrote: I will take a look at Transaction Control, but my first scan shows it is implementing its own connection pool? I wish to continue to use HikariCP as my pool, thus the source of my question. But let me give a little more background. I presently use Blueprint to define datasource XML files that are placed in the deploy directory. These files configure the datasource, wrap it in a pool, and register it in JNDI where applications then look it up. I understand this isn't necessarily the recommended approach anymore, so was looking at alternatives and it appeared Pax-JDBC is one of if not the recommended approach now. And when I saw support for HikariCP as a pool with 1.0, I took a deeper look. So I have the necessary Pax features installed and have my org.ops4j.datasource-<name>.cfg file created and I do get a data source created and pool created for it. My file is: osgi.jdbc.driver.name<http://osgi.jdbc.driver.name/>=mysql pool=hikari databaseName=person_trunk user=<removed> password=<removed> dataSourceName=mydatasource This works, but I'd like to control some of the HikariCP pool settings. The link pointed to earlier (https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+in+1.0.0) says: In addition you can also set pooling properties that start with "pool.". These will be forwarded to the pooling library. Thus, I tried setting pool.minimumIdle=5 and jdbc.pool.minimumIdle=5 but both result in errors as the setting is forwarded to the MySQL data source factory. So, how can I specify my pool settings in a way that they are forwarded to the pooling library? If there is a alternate/better way to configure Pax-JDBC and use HikariCP as the pool, or other alternatives to Pax-JDBC, I'm all ears. Thanks, Kevin On Wed, Mar 1, 2017 at 2:42 AM, Timothy Ward <tim.w...@paremus.com<mailto:tim.w...@paremus.com>> wrote: Transaction Control can already be used with a DataSource, Driver, DataSourceFactory, you name it. It also doesn’t have special configuration, it’s config admin just like everything else. The scoped connection is also not special, and can be passed to all manner of other libraries. You can even wrap it in a DataSource which hands out the same connection to everyone, just like Spring do with their SingleConnectionDataSource. Regards, Tim On 1 Mar 2017, at 10:28, Christian Schneider <ch...@die-schneider.net<mailto:ch...@die-schneider.net>> wrote: It would be nice if the transaction control service would also support DataSources as services. So would would only need to teach people one variante to configure them. Transaction control is special in its config and it can not be reused for other usages of a database. Christian 2017-03-01 10:44 GMT+01:00 Timothy Ward <tim.w...@paremus.com<mailto:tim.w...@paremus.com>>: Again, I can recommend the OSGi Transaction Control service. The Aries implementation has support for configuration defined resources, which make connection and pooling configuration extremely easy. See http://aries.apache.org/modules/tx-control/localJDBC.html#creating-a-resource-using-a-factory-configuration for details. The Aries Transaction Control implementation also has support for XA transactions if that’s of interest to you. Best Regards, Tim Ward Author, Enterprise OSGi in Action https://www.manning.com/cummins On 1 Mar 2017, at 08:11, schmke <ktschm...@gmail.com<mailto:ktschm...@gmail.com>> wrote: I too am trying out the HikariCP pooling and haven't figured out how to change/specify pool settings. I have a .cfg file that creates a pooled data source just fine, with TRACE logging on I see HikariCP initializing and all the default settings. And the pool is used as I use the data source. But when I try to specify pooling configuration in the .cfg file, the property I set is passed on to the underlying data source factory, not the pool. For example, I want to set the minimumIdle to 5 rather than the default 10. If I specify pool.minimumIdle=5 I see this in the log: 2017-03-01T00:08:13,848 | WARN | CM Configuration Updater (ManagedServiceFactory Update: factoryPid=[org.ops4j.datasource]) | DataSourceRegistration | 76 - org.ops4j.pax.jdbc.config - 1.0.1 | cannot set properties [pool.minimumIdle] java.sql.SQLException: cannot set properties [pool.minimumIdle] at org.ops4j.pax.jdbc.mysql.impl.MysqlDataSourceFactory.setProperties(MysqlDataSourceFactory.java:71) [77:org.ops4j.pax.jdbc.mysql:1.0.1] If I instead specify jdbc.pool.minimumIdle=5, the same thing: 2017-03-01T00:09:04,034 | WARN | CM Configuration Updater (ManagedServiceFactory Update: factoryPid=[org.ops4j.datasource]) | DataSourceRegistration | 76 - org.ops4j.pax.jdbc.config - 1.0.1 | cannot set properties [pool.minimumIdle] java.sql.SQLException: cannot set properties [pool.minimumIdle] at org.ops4j.pax.jdbc.mysql.impl.MysqlDataSourceFactory.setProperties(MysqlDataSourceFactory.java:71) [77:org.ops4j.pax.jdbc.mysql:1.0.1] So how are the properties to be specified so they get passed to the pool and not the underlying JDBC data source? -- View this message in context: http://karaf.922171.n3.nabble.com/PAX-JDBC-1-0-1-pools-tp4049649p4049697.html Sent from the Karaf - User mailing list archive at Nabble.com<http://nabble.com/>. -- -- Christian Schneider http://www.liquid-reality.de<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de> Open Source Architect http://www.talend.com<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
