Improve Session opening efficiency
Description
Attachments
2
Activity
Show:
Kostya Stern December 8, 2019 at 6:55 PM
Hello,
It looks like this task broke functionality related to property org.hibernate.flushMode. If I have the following persistence.xml :
I still get entityManager.getFlushMode() = AUTO.
But if I try to use this configuration in 5.4.4 , I will get entityManager.getFlushMode() = COMMIT as expected.
Thanks.
Sanne Grinovero August 19, 2019 at 12:13 PM
Attached two flamegraphs which highlight the improvements of my work in progress on this one.
It’s also including as they are strongly related, it would not be sensible to measure one without the other.
Opening a new Session has become quite resource intensive: several configuration properties are being duplicated and parsed, and it turns out most of these operations are going to be the same for all Session instances when opened with the default settings.
This can be improved in various ways; I'm planning to introduce a new component to be layered between the SessionFactory and the Session instances. In terms of roles this is similar to the SessionBuilder, except that the builder is by its nature unique for each Session and is collecting settings which make a Session unique - while the new component (planned to be called FastSessionServices ) is having a design emphasis on the immutable state to be shared across all Sessions (unless they use special flags to diverge).
Such new component can als be used to cache / prepare frequently looked up elements from the SessionFactory, such as particularly hot Services or anything similarly threadsafe, unique.
Configuration properties of a Session also need to be called out: literally having to parse Map<String, Object> props at each session open is not great for performance; not least each session is having its own copy of such properties, while we could use a copy-on-write approach to share the default settings among all sessions.