Commit Graph

8 Commits

Author SHA1 Message Date
Carlos Ruiz f76c39889c
IDEMPIERE-5013 set HikariCP initial pool size to 10 - as it was in c3p0 (#1564) 2022-11-16 15:22:11 +08:00
Jasper Siepkes 0173bbd296
Fixed user defined JDBC URL override not working. (#1499)
Fixes logic error in the way a user defined `jdbcUrl` in
`hikaricp.properties` is handled.

Additionally changed the default max pool size to the previous limit of
90 connections. PR #926 originally also had this but this apparantly
fell out. Testing showed that during first time server startup a flood
of connection can be made and a connection pool of 30 can be
overwhelmed and callers waiting on a connection will time-out.
2022-09-26 15:45:05 +08:00
Jasper Siepkes 861e3ad01f
IDEMPIERE-5013 Implement HikariCP as a replacement for c3p0 (#926)
* Replaced PostgreSQL and Oracle connection pools with HikariCP.

Replaced C3P0 with HikariCP. HikariCP is a Apache licensed connection pool with substantially better performance and better resilience to failure (DB disconnects, etc.) then C3P0. Read more about it here: https://github.com/brettwooldridge/HikariCP .

Cleaned up the `getCachedConnection` method. With HikariCP there is no need to retry to obtain a connection since getting an connection will block until a free connection is available or until a timeout is reached (default 30 seconds) at which point an `SQLException` is thrown. This also removed calling `Runtime.getRuntime().runFinalization();`. HikariCP is currently configured to detect / log leaks when a connection hasn't returned to the pool for longer then 5 minutes.

Loading of pool config properties was cleaned up. Defaults are now loaded from a single file instead of defaults coming from both file and hardcoded properties. It is now also possible to specify any HikariCP property in the user pool property file.

Initialization of the datasource must happen in the `getDataSource()` method because at object construction not all JDBC config is known. However this method could (as far as I could tell) be called concurrently from multiple threads but had no mechanism to prevent initializing the DB pool multiple times. The variable in which the pool itself was stored (`m_ds`) also was not marked volatile or immutable which could lead to visibility issues. Instead of lazy initialization of the pool in the `getDataSource()` method the pool could probably better be initialized at object construction. However I wasn't able to achieve that without breakage therefor I made the initialization mechanism work correctly with concurrent invocations.

Various config options such as the `MaxStatementsPerConnection` options were removed because HikariCP doesn't support them.

* (Re)added Sequence time-out.
2022-09-10 12:21:57 +02:00
Carlos Ruiz ac14fcd294 IDEMPIERE-3830 c3p0 defaults are not exploiting the power of c3p0 reliability 2018-11-28 22:17:48 +01:00
hieplq fc67e3d668 IDEMPIERE-2892:add config let out put log of c3p0 2015-10-19 20:37:01 +08:00
Heng Sin Low 8c05b86db1 IDEMPIERE-1093 Database: added connection pool properties file support. 2013-06-21 22:35:31 +08:00
Carlos Ruiz 43d195b4ce IDEMPIERE-1044 Load testing / set MaxPoolSize=90 by default to match the default postgresql max_connections=100 2013-06-12 00:11:12 -05:00
Heng Sin Low 0ed2e11bd0 Rename default connection pool properties file to server.default.properties and client.default.properties. This change would allow developer to create fragment to contribute a customize server.properties or client.properties 2011-01-19 16:55:38 +08:00