HikariCP module

[magicprinc]

Thank you very much for a great product! I can't believe that it is not mainstream instead of Hibernate!

I have made for my needs a HikariCP integration for Ebean. It is an easy-to-use seamless drop-in replacement for the bundled connection pool. https://github.com/magicprinc/hibean

It has even mappings file for ebean-to-hikari property mappings: https://github.com/magicprinc/hibean/blob/main/src/main/resources/ebean/ehpalias.properties so it is quite possibly to run it (after some additions to this file) without modifications of config file (i.e. with the same application.properties).

It also supports Spring Boot property-naming-convention.

I hope you enjoy it :-)

[rbygrave]

Nice !! Are you looking to contribute it to be part of ebean or ebean-datasource?

Spring Boot property-naming-convention.

By this we mean that it supports using the "spring.datasource" style prefix or something else?

Note that we can just supply a javax.sql.DataSource via DatabaseConfig.setDataSource() and DatabaseConfig.setReadOnlyDataSource(). I'd suggest the motivation for this and the benefits of using this approach are that:

• It seamlessly works with ebean-test
• It works with DatabaseConfig.setAutoReadOnlyDataSource(true)

Were those the motivation for doing this or was there something else that this helps with?

Default / Bundled connection pool

The bundled connection pool has its own "magic sauce" which sets it apart from all the datasource pools I know including HikariCP which is its strategy for testing connections (when to run connection validation).

The ebean datasource has a strategy of "testing on exception" + "testing in the background". "Testing on exception" means that any connection that is returned to the pool that threw a SQLException is validated. This works well because:

• Generally there is a low % of transactions that throw SQLException (unless we have totally lost connectivity)
• The pool immediately can detect connection issues and reset the pool
• The pool is robust, resets and recovers well

HikariCP tests based on elapsed time + in the background. Other pools use "test on borrow" or "test on return" but then that adds overhead every single time a connection is obtained.

HikariCP internally takes the path of ThreadLocal based caching. Ebean DataSource pool takes the path of internal data structures optimised for holding "busy" and "idle" connections with pre-sized arrays based on maxConnections etc (I'm unconvinced that ThreadLocal is a good long term strategy here with respect to Loom / Virtual Threads). Ebean DataSource pool includes PreparedStatement caching and HikariCP leaves that to the driver. Ebean DataSource pool defaults to "automatic size tuning" meaning that we just allow the pool to grow (up to max) and shrink based on maxIdleTime and this works very well in practice wrt pool sizing. There are differences of opinion and implementation as you would expect.

Today, for anyone who asks me, I still very much recommend using the Ebean DataSource pool. I believe it is the most robust pool. It is also very fast although it may not be quite as fast as HikariCP with its ThreadLocal based caching.

Cheers, Rob.

Edit: Made some edits to this adding some extra details.

[magicprinc]

Thank you so much for such a thoughtful response! And again, thank you so much for Ebean! :-)

Are you looking to contribute it to be part of ebean or ebean-datasource?

If you want, you can use any part of HiBean project as you want: all permissions are granted.

The main reason to publish the link here, to give a solution if somebody asks "How to use Ebean with HikariCP" (without Spring etc.)

By this we mean that it supports using the "spring.datasource" style prefix or something else?

This too, but not as a main meaning. I mean this: max-lifetime: 42 It is equal to max_lifetime: 42 and maxLifetime: 42

The module is used internally in tests without Spring context and all developers are used to Hikari. We don't have a DataSource to put in DatabaseConfig.setDataSource() so to say. Sometimes we reuse (copy paste) configs from application.properties so It is nice to have. The actual prefix is configurable. So no offense intended.

BTW I think your pool is in the shadow of Ebean. Probably it is a good idea to give it more standalone publicity?

For example: developers from Red Hat have developed their own connection pool, used primarily (as I know) in Quarkus. But the pool has its own project page https://agroal.github.io/about.html and claims it is better than HikariCP.

After such a detailed comparison of the internal structure of your pool and HikariCP, I have a question: Maybe you have an opinion about Agroal too?