Closing the context can hang when Hikari pool suspension is enabled - #52276

HikariCheckpointRestoreLifecycle is a plain Lifecycle, so its stop() method is called whenever the application context is closed, not only before a checkpoint. With spring.datasource.hikari.allow-pool-suspension=true, which the lifecycle's warning asks for when org.crac is on the classpath, stop() suspends the pool before beans are destroyed. A bean that borrows a connection while it is being destroyed then blocks forever, as HikariCP's SuspendResumeLock uses Semaphore.acquireUninterruptibly() while the pool is suspended.

For example, with Hibernate and an embedded database, where ddl-auto defaults to create-drop, the schema is dropped when the EntityManagerFactory is closed and context.close() never returns:

java.util.concurrent.Semaphore.acquireUninterruptibly(Semaphore.java:341)
com.zaxxer.hikari.util.SuspendResumeLock.acquire(SuspendResumeLock.java:72)
com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:154)
...
org.hibernate.tool.schema.internal.exec.GenerationTargetToDatabase.getIsolatedConnection(GenerationTargetToDatabase.java:57)

The same application closes normally with allow-pool-suspension=false.

This change makes stop() return early when the context is being closed, as the data source is closed during bean destruction anyway. The warning about pool suspension was already skipped in that case, so its own check is no longer needed. The new test in HikariCheckpointRestoreLifecycleTests fails without the change.

One case this doesn't cover: if the context is stopped, which suspends the pool, and then closed without being started again, the lifecycle is no longer running at close so the pool remains suspended. I wasn't sure whether that's something you'd want handled, so I've left it out.

I used an AI coding assistant for parts of the analysis; I reviewed and verified the change and tests myself.