Quite straightforward actually or maybe I’m not understanding you correctly. Could you post an example?

A) The context :
Hi, for my project, I used Seam and its Seam Managed Persistence Context. Although I know this context is designed for Conversation scopes, I did not use them at all (all my application is Session scoped).

B) The problem
I had to make forms for different elements. Let us consider the “Country form”. I had to fill the form (name, currency…), view it and modify it. However, while modifying the form, I had to be able to perform a classic undo (using a hit on my cancel button) and then retrieve the state of my country as it was before I began doing updates…

C) The unsuccessful attempts and a first solution :
I just have to say it was a pity for me to do that using JPA. I tried all the methods the entityManager gave me (refresh and find mainly) to retrieve the first state of my country object… unsuccessfully Finally I made a clone object of me entity, perform the modifications on it and, when clicking the Validate button, re-copy the clone fields onto the real persisted object.
The clone technic drawbacks :
- The mechanic is quite simple but boring to implement…
- Easy to implement when you have “hello world” sample with 3 or 4 entities living quite independently from each other. But it’s a pity to maintain when you have dozens of entities all of them being part or collection of the other…

D) Another solution
So although it works, it was a pain to code and maintain. Taken good resolutions for this new year, I searched for other methods and found another one : try to detach the entity using the “evicts” method provided by Hibernate (which is the provider I used). No more clone here : you use directly the object from the database BUT you cut temporarily the connection between the database and Java. Doing so, I can finally persist the changes… or not (undo)! Great but… I see 2 drawbacks using this method :
- it is provider dependent (Hibernate in this case, although I suppose the same method may exist for other JPA implementation)
- the code is quite ugly because you have to load all the collections depending on the object BEFORE you perform this detach : if not, be prepare to have some nice LazyInitializationException…

As I said in a previous post, I’m quite new to JPA, so maybe I missed something but I greatly appreciate if someone could tell me whether or not he ever met such problems and what kind of solutions he had.

Thanks again for the great articles.

But I’ll answer your question for other readers of this blog: the difference is that a new entity is one that has just been created in Java but has not been persisted in the database yet, while a detached entity exists in Java and in the database but the Java entity is no longer attached to a session so any updates to it will not be reflected in the database.

Regards.

In our scenario the data comes from an external source in XML format (we use JAXB to unmarshal it), and needs to be merged with the one already in the DB. We use entityManager.merge in all cases.

In fact, the major problem is the transfer protocol – the data is coming as a complex deeply nested XML (think of the complete invoice, including information about the customer), so the DIY merge is problematic. We have chosen to specify the meaningful IDs in our entity beans and now it works completely transparently. The major problem was with the compound IDs and complex relationships between entities (and both simultaneously), but those were sorted eventually… Though, at this stage there’s a high risk for application to lose its independence from the JPA provider (for example, ours now works with OpenJPA only).

To speed up the development we successfully use HyperJAXB 3 (http://confluence.highsource.org/display/HJ3/Home), which generates 90% of the code, though still need to handcraft some JPA annotations anyway.

JpaDao {
  public void persist(E entity) {
    if (entity.getId() == null) {
      entityManager.persist(entity);
    } else {
      if (!entityManager.contains(entity)) {
        entityManager.merge(entity);
      }
    }
  }
}

As for the fact that I the serialization methods I use (Hessian, AMF/BlazeDS) apparently do not keep associations intact, I guess the problem here is that I am using domain objects as data transfer objects. That is a practice encouraged by the fact that you get away with in a lot of cases thanks to stuff like the ModelAndView and the WebDataBinder in Spring Web MVC.

When you use associations (especially ones that would make you walk the entire object graph) you usually do not want them all to be serialized, leaving you with this problem.

In fact I actually write separate DTO’s for my more complex domain models and then you always have manually copy/merge the received data to your domain object.