Скачать или смотреть Understanding Why Your Hibernate Persistent State Objects Don't Save to the Database

Discover how Hibernate's transaction management affects data persistence in your Java applications, with clear explanations and examples.
---
This video is based on the question https://stackoverflow.com/q/70231095/ asked by the user 'Denys_newbie' ( https://stackoverflow.com/u/13253563/ ) and on the answer https://stackoverflow.com/a/70231513/ provided by the user 'Nathan Hughes' ( https://stackoverflow.com/u/217324/ ) at 'Stack Overflow' website. Thanks to these great users and Stackexchange community for their contributions.

Visit these links for original content and any more details, such as alternate solutions, latest updates/developments on topic, comments, revision history etc. For example, the original title of the Question was: object in persistent state don't saved to the database, but successfully loaded from it

Also, Content (except music) licensed under CC BY-SA https://meta.stackexchange.com/help/l...
The original Question post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license, and the original Answer post is licensed under the 'CC BY-SA 4.0' ( https://creativecommons.org/licenses/... ) license.

If anything seems off to you, please feel free to write me at vlogize [AT] gmail [DOT] com.
---
Understanding Why Your Hibernate Persistent State Objects Don't Save to the Database

Hibernate is a powerful framework for managing database interactions in Java applications. However, sometimes developers encounter frustrating situations where objects in persistent state don’t seem to save correctly to the database. In this guide, we'll explore an example issue where data fetched from the database is not saved as expected and delve into the reasons behind this behavior.

The Problem

Imagine this scenario: you've created a Role entity and, after running your code, you notice that the database reflects an unexpected value. Specifically, one line of code outputs "role111", yet the database still shows "role11". Why does this discrepancy happen? Let's break down the code to understand the situation better.

Your Example Code

Here's a simplified version of the code you used:

[[See Video to Reveal this Text or Code Snippet]]

Database State

After executing the code, the state of the database was as follows:

idname1role11It appears that even though the Role object's name was eventually changed to "role111", the value in the database remained "role11".

The Underlying Issue

Temporary Persistence and Transactions

Transactional Write Behind: Hibernate works with a concept known as "transactional write behind". This means that when you call methods like save(), the updates are stored internally in your Hibernate session until a flush is triggered. A flush is typically prompted by committing a transaction or executing certain queries.

Committing Transactions: In your case, the transaction commit occurred after changing the role name from "role1" to "role11". This successfully saved that change to the database. However, when you changed the name to "role111" after the commit, no second commit was performed to save this new change back to the database.

Importance of flush Modes

Hibernate’s default flush mode is to flush on transaction commit. This means that unless you explicitly tell Hibernate to flush the session prior to committing, any changes made after the commit will not be saved in the database.

If you want to adjust when Hibernate executes these updates, you can modify the flush mode. For example, setting it to FlushModeType.AUTO will cause Hibernate to flush before certain query executions as well.

Conclusion

In summary, the reason your object’s changes were not reflected in the database comes down to how Hibernate manages transactions and flush operations. Understanding these concepts is key to effectively using Hibernate in your applications. Always remember:

Changes to persistent entities in Hibernate are not immediately written to the database.

Only the actions that occur before a transaction commit will have their changes saved.

If additional changes are made after a commit, a new commit is necessary to save those updates.

By keeping a close eye on these transactional behaviors, you can avoid surprises and ensure your application's data integrity.

With this knowledge, you should feel more empowered to debug and resolve issues within your Hibernate applications. Happy coding!