In the following example code given, it's flushing the persisted objects, clearing them from the context (I guess memory is still saved when these objects become detached from the JPA provider despite they are still living in memory within the application's code), and then commit at the very end so the previously flushed objects actually do get stored in the database.
The page also follows with suggesting the following better approach, which doesn't bother with the flush and jumps straight to the commit followed by a clear. So, it also uses the clear() method.
So the question is whether it is a good idea to call em.clear() every so often? A lot of the sample codes adopt the following flow.
Is it better to do the following instead (ie calling clear() after commit())?
If I don't call em.clear(), how would the JPA provider manage the entities either persisted / found to / from the dB? Does the memory use just continue to grow indefinitely?
Handles transactions automatically for methods that are annotated with the @Transactional annotation, saving the need to wrap every operation that modifies the database (such as persist) by transaction begin and commit.
So this means I can just do the following. But where can I place em.clear() now? If I put it at the end of the method, I have a feeling that it'd be called before the @Transactional end wrapping statement (ie em.getTransaction().commit();)!
What are you doing? You are supposed to be reading this tiny ad!
the new thread boost feature brings a LOT of attention to your favorite threads