Unnecessary read before update with merge()

[markvl]

Hope I'm not posting this to the wrong forum. I raised this first on the EJB3 and Hibernate user forums but have come to the conclusion it is a design / implementation issue with EJB3/Hibernate.

I have a simple case of an entity which is read in one thread, then updated in another thread using merge().

The Hibernate merge() code always reads the original value of a detached entity. From DefaultMergeEventListener.entityIsDetached():

 //we must clone embedded composite identifiers, or
 //we will get back the same instance that we pass in
 final Serializable clonedIdentifier = (Serializable) persister.getIdentifierType()
 .deepCopy( id, source.getEntityMode(), source.getFactory() );
 final Object result = source.get(entityName, clonedIdentifier);

It should be possible to update the entity without the original value of the entity being read from the DB. This is causing an unncecessary call to the DB.

[epbernard]

This is as per the spec. The behavior you want is available when you do session.saveOrUpdate()

Both have merit.

[epbernard]

To expand it a bit. If you expect mostly updates from your graph, saveOrUpdate is good, if you expect mostly unchanges objects in your graph, merge is good.

Hibernate optimize things under the hood (merge profile / batch update), the different does not matters in most cases

[markvl]

OK, so I can use an Hibernate extension to workaround the issue.

I see that the Hibernate doc says that merge() behaves this way (http://www.hibernate.org/hib_docs/entitymanager/reference/en/html_single/#d0e897), but where can I found the EJB3 spec stating this should be the behaviour of merge()? I can't find that being covered in the Sun doc.

It would be nice if the EJB3 spec provided a way of avoiding this inefficiency.