JPA flush vs commit

Question

in JPA, if we call EntityTransaction.commit(), does it automatically call EntityManager.flush()? or should we call them both? what is the difference? because i have problem with JPA, when i insert an entity to database, i call persist(). in the database, the data has been inserted (can be fetched), but that data doesn't show up in my app (i fetch it using findAll()). and on another entity, it showed up. is there something i don't know? i'm using standard Spring CRUD, JPA resource_local, and postgresql. sorry for my english, thanks in advance

your answer is different than the @singhakash. so what is the best practice ? — monterico, Feb 08 '15 at 10:33

score 20 · Answer 1 · edited Nov 07 '22 at 18:26

20

em.flush() - It saves the entity immediately to the database with in a transaction to be used further and it can be rolled back.

em.getTransaction().commit - It marks the end of transaction and saves all the changes with in the transaction into the database and it can't be rolled back.

Refer https://prismoskills.appspot.com/lessons/Hibernate/Chapter_14_-_Flush_vs_Commit.jsp

edited Nov 07 '22 at 18:26

Sandy

11,332
27
76
122

answered Feb 21 '19 at 06:14

Sanchi Girotra

1,232
13
13

1

Link is broken, can you update? – Abimaran Kugathasan Dec 02 '21 at 15:05

score 18 · Accepted Answer · edited May 23 '17 at 11:54

if we call EntityTransaction.commit(), does it automatically call EntityManager.flush()?

Yes

what is the difference?

In flush() the changes to the data are reflected in database after encountering flush, but it is still in transaction.flush() MUST be enclosed in a transaction context and you don't have to do it explicitly unless needed (in rare cases), when EntityTransaction.commit() does that for you.

Source

score 10 · Answer 3 · answered Nov 15 '17 at 16:03

If you have a @Version annotated column in your entity and call entityManager.flush(), then you will either (immediately!) get an OptimisticLockException, or the database will lock this row (or table). In the later case you can still call setRollbackOnly(), and the lock will later be released without a DB change.

Or from a different perspective, with flush() you can create a (pessimistic) lock on that database row. The others will still see the old entry, but if they try to update they will be blocked, until the lock is released.

All this is also true for CMT (container managed transactions). Instead of waiting for the moment, where the service method is finished and the CMT commit is performed, you can call flush() (even several times) in your service method and handle the OptimisticLockException(s) immediately.

This answer is almost irrelevant to the question, but very informative regardless. — giannis christofakis, Sep 25 '20 at 12:45

JPA flush vs commit

3 Answers3

Linked