Quantcast

PAX JDBC 1.0.1 pools

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

PAX JDBC 1.0.1 pools

Scott

I’m a bit confused on how to configure the underlying connection pool. I’ll be using the Hikari pool service.pax-jdbc-pool-hikaricp. Could someone point me to the docs or something? The only example I see is for DBCP and all my experiments thus far have failed.

 

Thx, Scott

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

Timothy Ward
Hi Scott,

The OSGi Transaction Control service has built in support for connection pooling. There's an en route example here:
https://github.com/osgi/osgi.enroute.examples.jdbc

Regards,

Tim

Sent from my iPhone

On 24 Feb 2017, at 16:12, Leschke, Scott <[hidden email]> wrote:

I’m a bit confused on how to configure the underlying connection pool. I’ll be using the Hikari pool service.pax-jdbc-pool-hikaricp. Could someone point me to the docs or something? The only example I see is for DBCP and all my experiments thus far have failed.

 

Thx, Scott

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

cschneider
In reply to this post by Scott
See https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+in+1.0.0

For H2 and hikari you could use:
osgi.jdbc.driver.name=H2
pool=hikari
databaseName=test
user=sa
password=
dataSourceName=test2

To install in karaf:
feature:repo-add pax-jdbc 1.0.1
feature:install pax-jdbc-config pax-jdbc-pool-hikaricp pax-jdbc-h2

You should see a DataSource

service:list DataSource

[javax.sql.DataSource]
----------------------
 databaseName = test
 dataSourceName = test2
 felix.fileinstall.filename = file:/home/cschneider/java/apache-karaf-4.1.0/etc/org.ops4j.datasource-local.cfg
 osgi.jdbc.driver.name = H2
 osgi.jndi.service.name = test2
 password =
 service.bundleid = 55
 service.factoryPid = org.ops4j.datasource
 service.id = 120
 service.pid = org.ops4j.datasource.78e4961e-be81-4328-9d2e-6e6af73bebd1
 service.scope = singleton
 user = sa
Provided by :
 OPS4J Pax JDBC Config (55)


As far as I know hikari has no XA support or at least we do not support it.

Christian



On 24.02.2017 17:12, Leschke, Scott wrote:

I’m a bit confused on how to configure the underlying connection pool. I’ll be using the Hikari pool service.pax-jdbc-pool-hikaricp. Could someone point me to the docs or something? The only example I see is for DBCP and all my experiments thus far have failed.

 

Thx, Scott



-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: PAX JDBC 1.0.1 pools

Scott

That much I have. I was talking about the configuration that might be more pool specific, like:

 

poolName          =

maximumPoolSize   =

minimumIdle       =

idleTimeout       =

maxLifetime       =

 

From: Christian Schneider [mailto:[hidden email]] On Behalf Of Christian Schneider
Sent: Friday, February 24, 2017 11:30 AM
To: [hidden email]
Subject: Re: PAX JDBC 1.0.1 pools

 

See <a href="https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling&#43;and&#43;XA&#43;support&#43;in&#43;1.0.0"> https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+in+1.0.0

For H2 and hikari you could use:
osgi.jdbc.driver.name=H2
pool=hikari
databaseName=test
user=sa
password=
dataSourceName=test2

To install in karaf:
feature:repo-add pax-jdbc 1.0.1
feature:install pax-jdbc-config pax-jdbc-pool-hikaricp pax-jdbc-h2

You should see a DataSource

service:list DataSource

[javax.sql.DataSource]
----------------------
 databaseName = test
 dataSourceName = test2
 felix.fileinstall.filename = <a href="file:///\\home\cschneider\java\apache-karaf-4.1.0\etc\org.ops4j.datasource-local.cfg"> file:/home/cschneider/java/apache-karaf-4.1.0/etc/org.ops4j.datasource-local.cfg
 osgi.jdbc.driver.name = H2
 osgi.jndi.service.name = test2
 password =
 service.bundleid = 55
 service.factoryPid = org.ops4j.datasource
 service.id = 120
 service.pid = org.ops4j.datasource.78e4961e-be81-4328-9d2e-6e6af73bebd1
 service.scope = singleton
 user = sa
Provided by :
 OPS4J Pax JDBC Config (55)


As far as I know hikari has no XA support or at least we do not support it.

Christian



On 24.02.2017 17:12, Leschke, Scott wrote:

I’m a bit confused on how to configure the underlying connection pool. I’ll be using the Hikari pool service.pax-jdbc-pool-hikaricp. Could someone point me to the docs or something? The only example I see is for DBCP and all my experiments thus far have failed.

 

Thx, Scott

 

 

-- 
Christian Schneider
http://www.liquid-reality.de
 
Open Source Architect
http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: PAX JDBC 1.0.1 pools

schmke
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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

Timothy Ward
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 <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

cschneider
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 <[hidden email]>:
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 <[hidden email]> 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.




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

Timothy Ward
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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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.




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

schmke
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:

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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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.




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

Timothy Ward
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 <[hidden email]> 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:

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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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.




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

schmke
Ok, it just became more interesting!  Will try it today.

I'm still wanting to know how to get configuration properties for the pool to the pool using Pax-JDBC though.

On Wed, Mar 1, 2017 at 7:50 AM, Timothy Ward <[hidden email]> wrote:
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 <[hidden email]> 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:

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.


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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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.




--
--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: PAX JDBC 1.0.1 pools

Scott
In reply to this post by Timothy Ward

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:[hidden email]]
Sent: Wednesday, March 01, 2017 9:50 AM
To: [hidden email]
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 <[hidden email]> 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:

 

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 (<a href="https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling&#43;and&#43;XA&#43;support&#43;in&#43;1.0.0">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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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.

 



 

--

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

 

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

Timothy Ward
Hi Scott,

Well spotted!

The real key is visible in the metatype definition for the jdbc provider 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 <[hidden email]> 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 [[hidden email]] 
Sent: Wednesday, March 01, 2017 9:50 AM
To: [hidden email]
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 <[hidden email]> 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:
 
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.
 
 
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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.
 


 
-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: PAX JDBC 1.0.1 pools

Scott

I apologize, I don’t believe I was clear. My question was intended to get the distinction between osgi.idle.timeout and osgi.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:[hidden email]]
Sent: Friday, March 03, 2017 10:50 AM
To: [hidden email]
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 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 <[hidden email]> 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 [[hidden email]] 
Sent: Wednesday, March 01, 2017 9:50 AM
To: [hidden email]
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 <[hidden email]> 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:

 

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 (<a href="https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling&#43;and&#43;XA&#43;support&#43;in&#43;1.0.0">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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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.

 



 

-- 

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

Timothy Ward
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 <[hidden email]> 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 [[hidden email]] 
Sent: Friday, March 03, 2017 10:50 AM
To: [hidden email]
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 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 <[hidden email]> 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 [[hidden email]] 
Sent: Wednesday, March 01, 2017 9:50 AM
To: [hidden email]
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 <[hidden email]> 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:
 
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.
 
 
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
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 <[hidden email]> 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.
 


 
-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: PAX JDBC 1.0.1 pools

Scott

Hadn’t really thought of the versioning issue. Like I said, not an issue I have at the moment. Thx.

 

From: Timothy Ward [mailto:[hidden email]]
Sent: Friday, March 03, 2017 11:39 AM
To: [hidden email]
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 <[hidden email]> 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 [[hidden email]] 
Sent: Friday, March 03, 2017 10:50 AM
To: [hidden email]
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 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 <[hidden email]> 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 [[hidden email]] 
Sent: Wednesday, March 01, 2017 9:50 AM
To: [hidden email]
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 <[hidden email]> 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:

 

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 (<a href="https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling&#43;and&#43;XA&#43;support&#43;in&#43;1.0.0">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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:

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 <[hidden email]> 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.

 



 

-- 

-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: PAX JDBC 1.0.1 pools

cschneider
In reply to this post by Scott
Hi Scott,

sorry for the late response. Took a while until I found time to look into the hikari pool code.

You need to prefix the hikari properties with "hikari.".
All these properties will be stripped of the prefix and given to Hikari as the config map.

Christian

On 24.02.2017 18:35, Leschke, Scott wrote:

That much I have. I was talking about the configuration that might be more pool specific, like:

 

poolName          =

maximumPoolSize   =

minimumIdle       =

idleTimeout       =

maxLifetime       =

 

From: Christian Schneider [[hidden email]] On Behalf Of Christian Schneider
Sent: Friday, February 24, 2017 11:30 AM
To: [hidden email]
Subject: Re: PAX JDBC 1.0.1 pools

 

See https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+in+1.0.0

For H2 and hikari you could use:
osgi.jdbc.driver.name=H2
pool=hikari
databaseName=test
user=sa
password=
dataSourceName=test2

To install in karaf:
feature:repo-add pax-jdbc 1.0.1
feature:install pax-jdbc-config pax-jdbc-pool-hikaricp pax-jdbc-h2

You should see a DataSource

service:list DataSource

[javax.sql.DataSource]
----------------------
 databaseName = test
 dataSourceName = test2
 felix.fileinstall.filename = file:/home/cschneider/java/apache-karaf-4.1.0/etc/org.ops4j.datasource-local.cfg
 osgi.jdbc.driver.name = H2
 osgi.jndi.service.name = test2
 password =
 service.bundleid = 55
 service.factoryPid = org.ops4j.datasource
 service.id = 120
 service.pid = org.ops4j.datasource.78e4961e-be81-4328-9d2e-6e6af73bebd1
 service.scope = singleton
 user = sa
Provided by :
 OPS4J Pax JDBC Config (55)


As far as I know hikari has no XA support or at least we do not support it.

Christian



On 24.02.2017 17:12, Leschke, Scott wrote:

I’m a bit confused on how to configure the underlying connection pool. I’ll be using the Hikari pool service.pax-jdbc-pool-hikaricp. Could someone point me to the docs or something? The only example I see is for DBCP and all my experiments thus far have failed.

 

Thx, Scott

 

 

-- 
Christian Schneider
http://www.liquid-reality.de
 
Open Source Architect
http://www.talend.com


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: PAX JDBC 1.0.1 pools

Scott

Ah, ok. Like the other person who posted on this, had tried both pool and pool.jdbc to no avail. That seems to be what the documentation indicates.

 

Thanks for the update.

 

From: Christian Schneider [mailto:[hidden email]] On Behalf Of Christian Schneider
Sent: Monday, March 06, 2017 9:18 AM
To: [hidden email]
Subject: Re: PAX JDBC 1.0.1 pools

 

Hi Scott,

sorry for the late response. Took a while until I found time to look into the hikari pool code.

You need to prefix the hikari properties with "hikari.".
All these properties will be stripped of the prefix and given to Hikari as the config map.

Christian

On 24.02.2017 18:35, Leschke, Scott wrote:

That much I have. I was talking about the configuration that might be more pool specific, like:

 

poolName          =

maximumPoolSize   =

minimumIdle       =

idleTimeout       =

maxLifetime       =

 

From: Christian Schneider [[hidden email]] On Behalf Of Christian Schneider
Sent: Friday, February 24, 2017 11:30 AM
To: [hidden email]
Subject: Re: PAX JDBC 1.0.1 pools

 

See <a href="https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling&#43;and&#43;XA&#43;support&#43;in&#43;1.0.0"> https://ops4j1.jira.com/wiki/display/PAXJDBC/Pooling+and+XA+support+in+1.0.0

For H2 and hikari you could use:
osgi.jdbc.driver.name=H2
pool=hikari
databaseName=test
user=sa
password=
dataSourceName=test2

To install in karaf:
feature:repo-add pax-jdbc 1.0.1
feature:install pax-jdbc-config pax-jdbc-pool-hikaricp pax-jdbc-h2

You should see a DataSource

service:list DataSource

[javax.sql.DataSource]
----------------------
 databaseName = test
 dataSourceName = test2
 felix.fileinstall.filename = <a href="file:///\\%5C%5Chome%5Ccschneider%5Cjava%5Capache-karaf-4.1.0%5Cetc%5Corg.ops4j.datasource-local.cfg"> file:/home/cschneider/java/apache-karaf-4.1.0/etc/org.ops4j.datasource-local.cfg
 osgi.jdbc.driver.name = H2
 osgi.jndi.service.name = test2
 password =
 service.bundleid = 55
 service.factoryPid = org.ops4j.datasource
 service.id = 120
 service.pid = org.ops4j.datasource.78e4961e-be81-4328-9d2e-6e6af73bebd1
 service.scope = singleton
 user = sa
Provided by :
 OPS4J Pax JDBC Config (55)


As far as I know hikari has no XA support or at least we do not support it.

Christian



On 24.02.2017 17:12, Leschke, Scott wrote:

I’m a bit confused on how to configure the underlying connection pool. I’ll be using the Hikari pool service.pax-jdbc-pool-hikaricp. Could someone point me to the docs or something? The only example I see is for DBCP and all my experiments thus far have failed.

 

Thx, Scott

 

 

-- 
Christian Schneider
http://www.liquid-reality.de
 
Open Source Architect
http://www.talend.com

 

 

-- 
Christian Schneider
http://www.liquid-reality.de
 
Open Source Architect
http://www.talend.com
Loading...