Hi Josh,
I'm not aware of any such significant performance penalties within jOOQ itself (although, in case you're using R2DBC, there may still be issues that I'm unaware of). There is also little risk of running into a concurrency issue within jOOQ. The only place I recall where there's some sort of locking is the reflection cache, but it's unlikely this will be the problem in your case.
Other than that, I'd look into:
Problems related to concurrency / load:
- Connection pooling. Does it have the right size (both too small and too large are problematic)
- Is anyone locking the table / rows, etc. or is there any other source of non-blocking contention, e.g. undo/redo log contention, cursor cache contention, etc.
- Does your server have too little RAM, etc.
Problems not strictly related to concurrency:
- Are you missing an index (specifically one that might not work with bind values, in case you're relying on a function based index)
In any case, your query taking ~100ms by "default" is already a hint that something's off. Unless you're doing sophisticated reporting, most queries should take less than 10ms per execution, so any load related performance issue might also be addressed by improving individual execution performance, as these queries tend to keep resources busy for way too long.
Depending on your RDBMS, you may be able to analyse this directly in the database itself. E.g. Oracle Enterprise Manager can greatly help troubleshoot such problems for Oracle or MySQL databases.
I hope this helps,
Lukas