Hikaricp: [Feature] HikariDataSource with start/stop

[TuomasKiviaho]

I know that suspend/resumePool got already deprecated and JMX is not what I want to use but I'll suggest this anyway....

My use case consists of HikariDataSource instantiated without giving the HikariConfig because this would lead to premature generation of Hikari housekeeping and fail-fast failing too fast. Problem is that this way of construction allows me only lazy initialization of the pool.

What I'd would like is an option to start the pool (and hopefully a option to stop it) when IoC decides that the environment around data source is ready. The start method would consist of what is currently done in the other constructor.

      LOGGER.info("{} - Starting...", configuration.getPoolName());
      pool = new HikariPool(this);
      LOGGER.info("{} - Start completed.", configuration.getPoolName());

The stop can throw InterruptedExeption and shutdown the pool before pool = null for all I care. fastPathPool of course stays final for the double check pattern to be effective.

[TuomasKiviaho]

Actually the only thing I'd be needing is private volatile HikariPool pool; -> protected volatile HikariPool pool; because I have to currently use reflection.

private static class HikariDataSourceImpl extends HikariDataSource {

        @org.apache.felix.dm.annotation.api.Start
        void start() throws NoSuchFieldException, IllegalAccessException {
            Field field = (Field) HikariDataSource.class.getField("pool");
            field.setAccessible(true);
            HikariPool hikariPool = new HikariPool(this);
            field.set(this, hikariPool);
        }

}

[brettwooldridge]

suspend/resume is not deprecated, btw. And you can obtain the MBeans from methods on the HikariDataSource. Regarding your specific use case, we don't want to expose the pool instance directly, it's too fragile and users can cause too many problems that we end up debugging and chasing after. Let me think on it for a bit.

[keirlawson]

I'd also like to start the pool in a non-lazy fashion, my use case is a desktop application that is started and stopped often, so I don't want users to pay the price of spinning up the pool on the first query, as there will be a lot of first queries.

[billoneil]

A simple workaround to that is run a test / health check query when you want the pool to be initialized. As soon as you start the app run SELECT 1; and the pool will be initialized.

[brettwooldridge]

@keirlawson if you construct the HikariDataSource with the no-arg constructor the pool will lazily initialize on the first call to getConnection(). However, if you construct a HikariConfig first and use the constructor that accepts it as an argument, the pool will initialize immediately.