132

I was gathering information about the flush() method, but I'm not quite clear when to use it and how to use it correctly. From what I read, my understanding is that the contents of the persistence context will be synchronized with the database, i. e. issuing outstanding statements or refreshing entity data.

Now I got following scenario with two entities A and B (in a one-to-one relationship, but not enforced or modelled by JPA). A has a composite PK, which is manually set, and also has an auto-generated IDENTITY field recordId. This recordId should be written to entity B as a foreign-key to A. I'm saving A and B in a single transaction. The problem is that the auto-generated value A.recordId is not available within the transaction, unless I make an explicit call of em.flush() after calling em.persist() on A. (If I have an auto-generated IDENTITY PK then the value is directly updated in the entity, but that's not the case here.)

Can em.flush() cause any harm when using it within a transaction?

MicSim
  • 26,265
  • 16
  • 90
  • 133

3 Answers3

184

Probably the exact details of em.flush() are implementation-dependent. In general anyway, JPA providers like Hibernate can cache the SQL instructions they are supposed to send to the database, often until you actually commit the transaction. For example, you call em.persist(), Hibernate remembers it has to make a database INSERT, but does not actually execute the instruction until you commit the transaction. Afaik, this is mainly done for performance reasons.

In some cases anyway you want the SQL instructions to be executed immediately; generally when you need the result of some side effects, like an autogenerated key, or a database trigger.

What em.flush() does is to empty the internal SQL instructions cache, and execute it immediately to the database.

Bottom line: no harm is done, only you could have a (minor) performance hit since you are overriding the JPA provider decisions as regards the best timing to send SQL instructions to the database.

Flavio
  • 11,925
  • 3
  • 32
  • 36
  • 1
    What he said. em.flush() behaviour echoes java.io.Flushable.flush() where all buffered data are sent to whatever destination is appropriate. – Erik Nov 25 '10 at 10:29
  • 7
    if flush() sends data to the database? what happens if an exception is thrown after that? Will the entity manager rollback everything? even the data written in the first flush? – Jaime Hablutzel Jun 17 '11 at 02:44
  • 129
    flush() sends SQL instructions to the database like INSERT, UPDATE etc. It will not send a COMMIT, so if you have an exception after a flush(), you can still have a complete rollback. – Flavio Jun 20 '11 at 08:08
  • 20
    You can rollback the DB, but it will not rollback any changes to the objects, e.g., auto-incremented 'version', autogenerated ID, etc. Furthermore the entity manager will be closed after a rollback. Just beware that if you try to 'merge' the object to another session, the auto-incremented 'version' in particular may cause an OptimisticLockException. – Peter Davis Jun 26 '11 at 02:25
  • 14
    Apart from triggering side effects, another reason to use flush() is if you want to be able to read the effects of an operation in the database using JPQL/HQL (e.g. in a test). JPA cannot use cached data when executing these queries, so only stuff that's actually in the DB will be read. – sleske Jul 20 '11 at 10:15
  • @Flavio To prove what you said "generally when you need the result of some side effects" I tested flush against a before insert trigger. I don't see trigger triggering after the flush. In that trigger I am inserting in a different table. I am wondering, if it is because a trigger is part of a transaction as well? – Abidi May 04 '14 at 08:24
  • 1
    The trigger should execute within the same transaction. To check what I said, you should execute the insert, flush, then perform a select on the different table. With the flush, the select should always find the new values; without, it might not find them. – Flavio May 05 '14 at 17:01
  • 1
    An important notion to better understand difference between flush and commit, is "Transaction isolation level". If set to "Read Committed", then a transaction are allowed only to read data that has already been committed (not flushed) by other transactions. – kolobok Aug 07 '14 at 11:07
  • About isolation levels: http://stackoverflow.com/questions/16162357/transaction-isolation-levels-relation-with-locks-on-table?rq=1 (not configurable in JPA, but is configurable in Hibernate, JDBC and some DB). – kolobok Aug 07 '14 at 11:17
  • @Flavio then what can you do to send the data? What's the exact statement? – sguan Oct 18 '15 at 17:36
  • Could it be that, unless I flush manually or hibernate flush it itself? there is no lock acquired in DB for the queries? – Vikash Mar 19 '21 at 10:51
7

Can em.flush() cause any harm when using it within a transaction?

Yes, it may hold locks in the database for a longer duration than necessary.

Generally, When using JPA you delegates the transaction management to the container (a.k.a CMT - using @Transactional annotation on business methods) which means that a transaction is automatically started when entering the method and commited / rolled back at the end. If you let the EntityManager handle the database synchronization, sql statements execution will be only triggered just before the commit, leading to short lived locks in database. Otherwise your manually flushed write operations may retain locks between the manual flush and the automatic commit which can be long according to remaining method execution time.

Notes that some operation automatically triggers a flush : executing a native query against the same session (EM state must be flushed to be reachable by the SQL query), inserting entities using native generated id (generated by the database, so the insert statement must be triggered thus the EM is able to retrieve the generated id and properly manage relationships)

Gab
  • 7,869
  • 4
  • 37
  • 68
6

Actually, em.flush(), do more than just sends the cached SQL commands. It tries to synchronize the persistence context to the underlying database. It can cause a lot of time consumption on your processes if your cache contains collections to be synchronized.

Caution on using it.

clemens
  • 16,716
  • 11
  • 50
  • 65
Ricardo Nakashima
  • 61
  • 1
  • 2