This makes sense as doobie is setting autoCommit=false before every transaction, but default hikari configuration sets up connections as autoCommit=true. This means that hikari needs to reset connections to autoCommit=true after doobie has finished with them.
Stack overflow suggests this may be a performance issue and that it is advised to configure hikari with the autoCommit setting you use most often.
We can obviously do that in application code. But would it be wise for the doobie.hikari.HikariTransactor#newHikariTransactor constructor to include a call to setAutoCommit(false) given that doobie generally works that way?
In my app we use the
doobie.hikari.HikariTransactor#newHikariTransactor
constructor to build a Hikari transactor.And we are seeing a lot of debug lines like so:
This makes sense as doobie is setting autoCommit=false before every transaction, but default hikari configuration sets up connections as autoCommit=true. This means that hikari needs to reset connections to autoCommit=true after doobie has finished with them.
Stack overflow suggests this may be a performance issue and that it is advised to configure hikari with the autoCommit setting you use most often.
We can obviously do that in application code. But would it be wise for the
doobie.hikari.HikariTransactor#newHikariTransactor
constructor to include a call tosetAutoCommit(false)
given that doobie generally works that way?I see some chatter in gitter about this over the years (https://gitter.im/tpolecat/doobie?at=58e3a907ad849bcf424e1fcd), so does seem to be a common source of confusion...