Mapper caching is ineffective

[stevenschlansker]

We expect to cache created row and column mappers by type, but currently this is not working at all, which is a moderate to large performance problem.

[mikeallen-toast]

Hello @stevenschlansker , do you have an update on fixing this issue or if there is a workaround? I've observed significant performance regressions after upgrading from jdbi2 -> jdbi3 (overall CPU usage of my application doubled and profiling shows jdbi3 is taking orders of magnitude more CPU time over jdbi2). I see that column and row mappers are a problem in profiling my application. Is there a way to register row and column mappers to work around this caching problem?

[stevenschlansker]

Hi @mikeallen-toast , there's no current work on improving this specifically. However, jdbi code can still be quite fast, you just have to be careful to re-use resources when possible. For example doing more work in a single transaction, preparing statements, the usual stuff.

Can you outline a bit more specifically about how your code is written, and where you see performance problems? There's usually opportunities to improve.

[mikeallen-toast]

Hi @stevenschlansker thanks for your response.

My application makes heavy use of on demand SqlObjects, and in many cases nested SqlObjects. For example we follow the Repository and DAO pattern, where our Repositories are SqlObjects created with jdbi.onDemand and use default method implementations with Transaction annotations to call multiple SQL queries defined within various DAO interfaces.

Profiling shows a lot of activity in the Proxy SqlObject classes.

I suspect that our use of the on demand SqlObjects for our Repository classes may be a particular issue, but I'm not positive.