So, to my sorrow, I recently found out that the old product uses hibernate.cfg.xml and the new product we're developing uses persistence.xml.
So, whilst developing for the new product, I ran into issues.
Issues where a query sent to the database, would trigger a flush of all my dirty changes in my Session to the database.
This is because the Session is running with FlushModeType.AUTO, which is the default.
Problem was,... I was at the moment still building an entity to be persisted, and it wasn't ready yet.
Apparently I now have to be very careful in which sequence I do things.
Suffice to say, I am not amused.
Either that, or I switch over to FlushModeType.COMMIT, which means I can query the database all I want, and the flushing of my dirty entities in the session will take place only when I commit.
This is very convenient, unfortunately the disadvantage is that I might not see the dirty data in the database during my queries. But I feel this is well worth it.
References
- Vlad Mihalcea - How does AUTO flush strategy work in JPA and Hibernate
- https://vladmihalcea.com/how-does-the-auto-flush-work-in-jpa-and-hibernate/
- Vlad Mihalcea - How do JPA and Hibernate define the AUTO flush mode
- https://vladmihalcea.com/how-do-jpa-and-hibernate-define-the-auto-flush-mode/
- GitHub - Jakarta Persistence project
- https://github.com/eclipse-ee4j/jpa-api
No comments:
Post a Comment