pgjdbc VS HikariCP

The method doAppendEscapeLiteral (Line 66) is a good example; https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main...

I didn’t take notes all the way down, but at the end of the day this method is invoked when a prepared statements’ parameters are being bound

Let's take CVE-2022-21724 which has a base score of 9.8 - Critical from NVD. This vulnerability has the following description on GitHub link:

Virtual threads are great but db drivers still have to tweak (mainly to remove synchronized I/O) to be compatible with loom. Postgres just recently merged the changes for loom https://github.com/pgjdbc/pgjdbc/issues/1951

You can see it for example in the Postgres driver here or the MS SQL driver here. Oracle of course has already released their driver as Loom ready.

See here for details, one of the Project Loom mainainers chimes in with the bad news -- looks like a Loom supported solution is a ways off, so rewriting library/application code that uses synchronized is the only way to actually benefit from Loom's virtual threads.

Any chance you could add a thought / opinion to https://github.com/pgjdbc/pgjdbc/issues/1951 ? Around synchronized & ReentrantLock etc. Any input would be greatly appreciated.

This is about types defined outside your business and that means you possibly don't have a chance to do better, e.g. PgPreparedStatement from PostreSQL driver.

Looks like HikariCP is also awaiting fixes for this https://github.com/brettwooldridge/HikariCP/pull/2055

I have used hikari and exposed to do this in the past with postgres, although other dialects are supported.

I found one suggestion from the author of HikariCP on how to address this, which I implemented and it worked. However, there are additional classes involved, and it feels a little clunky and hard to follow.

Not really, you can change some things in spring boot but doing so will typically trigger a refresh which is less reliable than restarting but still causes a large performance hit. You could probably do it with hikari if you really needed to but it's inadvisable to build your application around this mechanic.

# https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

Not familiar with Python but this thread about a Java connection pool might be interesting: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

Whatever you choose, presuming your app is database heavy, I highly recommend spending time on DB schema design to make all queries as short as possible, avoid relying on transactions, and keep your connection pool tiny. For reference: https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

You reminded me of the HikariCP library and it’s documentation: Clear and simple with references to other libraries trying to accomplish the same thing. It is not in the closure space though.

https://github.com/brettwooldridge/HikariCP