Working with rollbacks in JPA

First examples you could see about JPA shows you how easy is to work with it. Don't misunderstand me, I like JPA, we (the developers) need a standard in the ORM world.
What I mean is when you really start working in a project using JPA discover you must understand fine the standard and the ORM engine implementing it (in my case TopLink).

Previously, in another post I put a couple of links on how to detach entities, here I would like to point to another post, from David Van Couvering's blog, talking about transaction rollbacks.

Detach an entity from JPA persistence context

1 - Previously
Ok, you have designed a great domain model and then translete it to a database or, also much probably, have designed a great database and then generated the corresponding entity classes.

2 - Now
You have some GUI to get user input data. Easy. You create a new domain object (customer, product, bill or whatever else) and persist it through your favourite JPA engine.
Now you have some GUI that lists the available objects in your domain (again customer, product, bill or whatever else. I good idea could be obtain that objects in the way of domain object, I suppose for that reason you create a model, then you can change properties in some of that objects and store (persist) again those changes, so called merge changes.

3 - The question
Here comes the question. How can you detach an object from the persistence context? If you could get a dettached object you could modify its properties, then if the user agrees persist its new state or leave unchaged otherwise.

4 - The solution (or better say 'some of the solutions')
Detach an entity from JPA/EJB3 persistence context

Beyond the JPA and the possible cache problems

Yesterday I detect an strange behavior in a little JEE5 application: queried JPA data doesn't reflect the real state of the data when I was made changes on database through an external database client program.
Looking at google I found this very interesting post:
Understanding the cache of TopLink Essentials(GlassFish JPA)

Summarizing, the persistence provider, in this case TopLink maintains data in a session cache, maintaining it synchronized only if is modified through an EntityManager and it doesn't if you modify through an external tool. To avoid use the cache, with all its implication, you need to specify it explicitly.

Closing JPA EntityManger in web applications

I want to note this post from my neighborhood JavaNotepad.

When working with resources it's always important to ensure they are closed when not longer needed.
Working with JPA there are two kind of resources we can take care of: EntityManager and transactions.

Read...