Making JPA 2.0 better - thinking loud about refreshAll and clear(Entity)

JPA 1.0 spec is lean, provider independent, powerful and usable inside, as well as inside a n EJB-Container.  However in some circumstances the JPA 1.0 requires still some workarounds:


1. I miss the method clear(Entity entityToDetach) for a particular entity. I use JPA in an unmanaged environment (Java SE 6) - such a method would simplify detaching the passed entity without clearing the whole cache. This is especially useful in stateful environments, where the Entities are bound to the UI (e.g. JSF, Seam, Rich Clients). JPA 1.0 only supports the method clear(), which detaches all entities or the whole entity manager… In my opinion it would be a nice extension for JPA 2.0.


2. I miss the refresh() (or refreshAll()) as well. In this case all attached Entities of an EntityManager should be refreshed. Now you have to do the bookkeeping of all known entities and refresh them on demand. This could be actually really useful for refreshing the whole workspace and preventing optimistic collisions. Of course refreshing the whole workspace could be slow, however keeping track of all entities and refreshing them sequentially is even slower.


What was your experience so far? Your feedback is appreciated, we are discussing these topics now in the JPA-EG - so you could change the future :-).


I would appreciate the possibility to create a two-dimensional history for JPA-Entities. Is this a feature request which belongs to JPA or do i have to ask the providers Toplink/Hibernate...?

Posted by Daniel on November 29, 2007 at 02:53 PM CET #


give me a sample please,



Posted by Adam Bien on November 29, 2007 at 03:58 PM CET #

with 2dimensional i mean that objects have both a functional(in german fachlich) and a technical history.
A sample
There s an object Vertrag
its functional attributes are: (Date) stateValidTo and stateValidFrom.
The technical attributes are: createdAt/By, modifiedAt/By and object_invalidatedAt
Whenever you create such a statedObject like Vertrag, you create it at a specific valuta (e.g. 1.1.2007.
Then this object gets a State=1 with stateValidFrom=valuta and stateValidTo = MAX_DATE (
If you like to modifiy a statedObject, you change the valuta to another date (e.g. 1.4.2007).
Now, the first state gets invalidated and two new stated will be created
State 1: objectValidFrom = 1.1.07 objectValidTo = MAX_DATE --> invalidatedAT = SystemDate
State 2: objectvalidFrom = 1.1.07 objectValidTo = 31.3.2007
State 3: objectValidFrom = 1.4.07 objectVaidTo = MAX_DATE

I hope this sample is understandable.

Posted by on November 30, 2007 at 12:23 PM CET #

Sorry, I'm afraid it is too specific for JPA 2.0. However this is one of the common use cases which are often needed. A clear case for the PDO pattern: see :-),


Posted by Adam Bien on November 30, 2007 at 06:03 PM CET #

I definately see a UseCase for a method like clear(Entity entityToDetach). This should be in JPA 2.0 for sure.
But on the other hand I have never had the need for refresh or something like that, I would rather see a need for being able to "mark" a property to be generated through an insert or update trigger (Hibernate has this very handy feature).

My biggest JPA 2.0 wishes are:
- Manual Flush Mode
- Collections of Value Objects
- User Types
- Criteria Queries


Posted by Michael Plöd on December 01, 2007 at 02:30 AM CET #


thank you for your feedback. I miss clear(Entity entity) and refresh() (the whole Entity Manager) as well. Refreshing all persistent Entities in one method makes easier to reload all cached entities in stateful environment. There is no issue in transaction-scoped EM. Thank you for your feedback!

Posted by Adam Bien on December 01, 2007 at 12:50 PM CET #

I totally agree with Michael requirements ... all of them !! Specially manual flushmode.

Posted by Maximiliano Carrizo on May 17, 2009 at 09:07 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
...the last 150 posts
...the last 10 comments