save() performance - will saveAndFlush() be better?

Question

I would like to ask you about the performance of save() in CrudRepository. Firstly, an example of code.

for(int i=0; i<5000; i++){
    Example example = new Example(0, true, false, i, "example");
    example = exampleRepository.save(example);
    List<ChildExample> childExamples = new ArrayList<>();
    ChildExample childExample = new ChildExample(0, i, true, example);
    childExamples.add(childExample);
    childExampleRepository.saveAll(childExamples);
}

This is just an example, but everything has to stay at their position (e.g. creating a list of examples, then using saveAll, using cascade etc. It is not allowed).

What have I observed? The first 2000 objects were saved very fast - let's say: 10 minutes. But - next 2000 were saved in a much longer time, about 30 minutes. Why is that? Why saving each subsequent takes longer? What if I use JpaRepository and saveAndFlush()? Will this process be shortened if I use saveAndFlush()?

Answer 1

When you hit save() which is the equivalent of entityManager.persist(), the persistence provider does not implicitly perform an INSERT on the physical database. It simply stored the given entity in its Persistence Context. It has become managed in the current session cache (first level cache).

This is to prevent unnecessary overload of CRUD operations. By default, the changes are flushed on commit of the current transaction (or upon reaching a certain threshold of managed entities like in your case). An implicit flush may also be triggered when a SELECT operation is performed during the transaction which contains persisted entities somewhere in the JOINs (this is not the case here though).

When you use flush, the persistence provider is obliged to perform a physical save on the database at that moment.

But will it increase the performance? There is no clear answer to that question and it totally depends on each unique scenario. It is an option though and you need to perform a set of tests in order to find out.

You may also fiddle around with hibernate.jdbc.batch_size. You may gain a lot if you hit this configuration right for you particular circumstance.