Yanming Zhou

> Which returns the cached transaction isolation level stored by Hikari. The cached transaction isolation only available if `Connection::setTransactionIsolation` called, I think it could be improved here, but the network...

It's not related to HikariCP, Hibernate called `connection.createNClob()` but your jdbc driver (derby) doesn't implement it, then `SQLFeatureNotSupportedException` raised, it's expected behavior.

You should debug on `HikariConfig` first to ensure correct `maximumPoolSize` is applied, It looks like default pool size is used. https://github.com/brettwooldridge/HikariCP/blob/b40e6842080d2e7e5f8d56350aec20c49df0c9dd/src/main/java/com/zaxxer/hikari/HikariConfig.java#L57

I'm trying to fix this by https://github.com/brettwooldridge/HikariCP/pull/2147, would you take a look? @Young0516

> If someone provides a pull request with a fix and a unit test, I will be happy to merge it. @lfbayer I created https://github.com/brettwooldridge/HikariCP/pull/2133.

> Can you please provide additional integration tests for the cases of optimistic locking failures and removal of an entity that contains modifications? It's nothing related to optimistic locking but...

> The PR as it stands right now, is not acceptable. It will not throw an `OptimisticLockingException` in the case of concurrent modification. > > It is not about avoiding...

I've updated this PR, I suggest not to squash commits, at least the first commit should be kept as it is. @schauder

> The previous version might actually flush those changes, potentially triggering life cycle events, triggers and validations. We need to make sure the new version behaves in the same way....

> I'm very much against changing anything about the observed behaviour in this. While I agree that a lot of it is weird, there are going to be people relying...