• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

question on entityManager's merge/refresh/flush

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

Can someone explain how to understand the difference between the entityManager.merge(), refresh(), and flush() methods? when to use them correctly? Simple examples are welcome.

thanks

Helen

SCJP
SCWCD
SCJWD
 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Helen,

First, you need to understand well the difference between PersistenceContext and EntityManager.
A PersistenceContext is a set of entity instances.
A EntityManager is associated with a PersistenceContext and is used to create and remove persistent entity instances, to find entities by their primary key, and to query over entities.

For me, the PersistenceContext as a kind of cache of the database.

1/ Merge
Is used to merge the state of an existing entity into the PersistenceContext associated with the EntityManager.
Your entity's status change from detached to managed.
If your entity is new, it's the same as a persist().
But if your entity already exists, it will update it.

2/ Flush
Synchronize the persistence context to the underlying database.
All your entity will be insert/update/remove in the database.
No commit is done in the database.
It's useful when you need to do queries JPQL in the database and you want to see the changes you did in the PersistenceContext in the result of the query.

3/ Refresh
Refresh the state of an entity instance from the database, overwriting changes made to the entity, if any.
The contrary of flush...

Hope it helps.

Beno�t
 
Helen Ge
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, Beno�t

Thanks for your explaination.

For the entityManager.merge(), I still feel confused with the result of mergering the existing entity :


1) From MZ's guide:



For a given entity A, the merge method behaves as follows:


If A is a DETACHED entity, its state is COPIED into existing managed instance A' of the same entity identity, or a new managed copy of A is created.

If A is a NEW entity, a new MANAGED entity A' is created and the state of A is COPIED into A'.

If A is an existing MANAGED entity, it is IGNORED. However, the merge operation still cascades as defined below.

If A is a REMOVED entity, an IllegalArgumentException is thrown.

The merge operation recurses on all relation fields of A whose cascades include CascadeType.MERGE.





2) From O'Reilly book 'Enterprise Java Bean 3.0'



If the entity manager isn't already managing a Cabin instance with the same ID, a full copy of the cabin parameter is made and
returned from the merge( ) method. This copy is managed by the entity manager, and any additional setter methods called on
this copy will be synchronized with the database when the EntityManager decides to flush. The cabin parameter remains
detached and unmanaged.

If the entity manager is already managing a Cabin instance with the same primary key, then the contents of the cabin
parameter are copied into this managed object instance. The merge( ) operation will return this managed instance. The cabin
parameter remains detached and unmanaged
.




I would more agree with the O'Reilly EJB 3.0 and your explaination - merge the existing managed entity will basically update the state of that entity.

I don't quite understand the explaination on MZ's

IGNORED

.


Can anyone share with your thinking?


thanks

Helen
 
Benoît de Chateauvieux
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Helen,

MZ just put an extract of the specs.
You can find the complete sentence at chapter 3.2.4.1 of persistence specs.
For me, it is the unique reference: O'Reilly books helps you understand but the specs is the truth.

Beno�t
 
Ranch Hand
Posts: 70
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Helen,
It made me think ..
but, as i understand, if the instance is managed, every change we've done to it will be synchronized automatically when the transaction commits.. that's why there's no point in calling merge, because there is nothing to merge, as all is up to date in the persitence context.
I would say that the concept of merge as itself is only related to detached entities.

It's just my interpretation of the specs.. maybe i'm wrong, and if so i'd like to be aware of it
[ April 25, 2008: Message edited by: Pedro Erencia ]
 
What are you saying? I thought you said that Santa gave you that. And this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic