• Post Reply Bookmark Topic Watch Topic
  • New Topic

Is mandating clearing the JPA context a good idea?  RSS feed

Mike Cheung
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there. I'm trying to understand more about managing the session / connection of my JPA use and am reading the following page:

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?

As a site note, interestingly enough, Spring provides the @Transactional annotation.
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();)!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!