Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Teams
Q&A for work
Connect and share knowledge within a single location that is structured and easy to search.
Learn more about Teams
1. execute 'DELETE' HQL query to remove user
2. call getEntityManager().flush();
3. call getEntityManager().clear();
If I understand clear() correctly, it will remove from context all persistent entities.
-source
However, I also read
here
,
you should define clear architecture- and design guidelines about where a
clear() can be called.
What are clear guidelines on when to call clear()?
The articles explains it. Clearing the entity manager empties its associated cache, forcing new database queries to be executed later in the transaction. It's almost never necessary to clear the entity manager when using a transaction-bound entity manager. I see two reasons to clear:
when doing batch processing, in order to avoid having a giant cache eating memory and increasing the time to flush because of long dirty checks
when you're doing DML or SQL queries, which completely bypass the entity manager cache (as in your example). In this case, the state held by the cache doesn't reflect what is in the database because of the queries, so you want to clear the cache to avoid this inconsistency.
–
–
–
–
Yeas, it's exactly depends on the architecture style of the platform as documentation points.
For example if in your application EM is thread's associated, then one of
the solutions for transaction management is to implement Session-Per-Request pattern which starts a transaction on each start of user's request and commit & clear the cache in each end of the request in order to prevent dirty reads. This is just a simple example
Other example is in a SOA platform. For each service could be also open a transaction in the beginning and commit it at the end with clearing (in case same EM is used by other service and avoiding of dirty reads is required)
I will replay the previous two common cases - batch processing one and bypassing in all possible cases the EM. So in this case queries will be forced to query from the DB , not from the cache.
You should know that you work with L1 and L2 caches and L1 is the cache cleared by EM. When you reads huge set of data (should be not the case)( then also clearing is required in a period.
As you see depends on the cases, architecture and style for your platform. Directly for your method - it's not a good practice to flush and clear cache per method, it's a anti pattern method.
TL;DR: use EntityManager.clear if you are about to perform a set of JPA operations where you don't need a majority of the entities that are already loaded
I recently had a performance issue which prompted me to ask how to get extra logging. Before I got the answer I found out how to fix the issue and that's through EntityManager.clear().
One use case I'd use it for is to isolate operations that may be intensive and load up a lot of entities for the entity manager to manage. In my case there's a step where I perform authorization checks. For most of the business logic in the remainder of the transaction, I don't need most of the data that it would have used (user profile, low level entity access checks, etc).
What I found was even if I don't use them it stays for the rest of the session and will eventually need to be flushed even if my processing was done already.
By doing a clear before the flush happens it releases them from the entity manager and are no longer managed.
–
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
