Hibernate is smart enough not to send insert/updates to the Database until it knows if the transaction will be committed or rolled back.
Lets understand the different Transaction :
- When you make a session session. save(a) Hibernate essentially remembers that this object needs to be saved somewhere inside the session. It may determine whether INSERT INTO… should be issued immediately, later, or on commit. Hibernate can now batch inserts or stop them if a transaction is rolled back, which improves consistency.
- Hibernate is forced to question INSERT INTO… against the database when you call session.flush(). The individual is in the database, but it hasn’t been committed yet. Other running transactions would not be able to see it, depending on the transaction isolation stage. However, the database is now aware of the record.
- Hibernate rolls back database transactions when you call transaction.rollback().
Consider the situation where there isn’t a flush (). First and foremost, since you never touch the database, efficiency is improved, and rollback is virtually eliminated. Other transactions, on the other hand, will see inserted records even before commit/rollback if the transaction isolation level is READ UNCOMMITTED. If Hibernate decides to flush() implicitly, this won’t happen without flush().