cache OMERO sessions in level 2 Hibernate cache#5281
Conversation
There was a problem hiding this comment.
If merged then this would be a 5.3 deprecation.
There was a problem hiding this comment.
Do you want to open a 5.3 PR and mark it as deprecated?
so we can/cannot remove it later on depending on outcome
|
I may have to go back and review the reasoning, but I'm remembering there being a reason (around stateful sessions or filters, etc) that we hid Hibernate's |
|
Add an API method to |
|
This looks nice and simple! One research-y question (if you happened to look into it while preparing this): is there anything we should take into account when it comes to this API in terms permitting external users to also enable the cache for HQL queries? My hope was always that we could enable all queries (but I don't know what the impact of that would be) |
|
Good question @joshmoore. I'd be hesitant to offer clients the choice of caching: the impression from my reading is that the query cache often does more harm than good (overhead in checking, invalidating, etc.), especially for data that might change, so the choice probably demands more subtlety and testing than we might expect from people writing scripts, etc., especially as this could impact other users of their server. I'm not even wholly convinced about this case here: VisualVM certainly suggests that this PR is a clear win in the expected places, but in my more real-world testing I don't see anything compelling either way emerging from the noise of varying times. In short: I doubt it's promising enough to be worth investigation / complication. Could well be worth revisiting once we're using Hibernate 5: of course I've largely been reading Hibernate 3 stuff. |
4 participants
What this PR does
Adjusts HQL queries of sessions in performance bottlenecks to enable caching.
Testing this PR
The server, especially integration tests, should in general run a little faster.
Related reading
https://trello.com/c/tYg2svfX/