Hi all,
I am having trouble using Hibernate as JPA provider. I must be also missing something, altough I've read the docs many times.

I want to create a bidirectional parent-child association, where the parent is the only responsible for managing the association.

Since I'm using DTO's, I have to make the ejb <> dto conversion.

I have a method updateScenario() that receives a full-blown scenario, including the dependency elements collection. This collection can contain new elements (which do not have id), and old ones (which do have an id).
Because I have to use dtos, when I update my scenario I'm merging an unmanaged scenario instance that was converted from my DTO:


but that doesn't work. Can you tell me what I am doing wrong?

Hibernate version:
3.2.5.GA, with Hibernate entity manager 3.3.1.GA
Mapping documents:
This is the parent mapping



This is the child mapping


Full stack trace of any exception that occurs:
org.springframework.orm.hibernate3.HibernateSystemException: A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance: ScenarioEJB.dependencyElements; nested exception is org.hibernate.HibernateException: A collection with cascade="all-delete-orphan" was no longer referenced by the owning entity instance: ScenarioEJB.dependencyElements
at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:659)
at org.springframework.orm.jpa.vendor.HibernateJpaDialect.translateExceptionIfPossible(HibernateJpaDialect.java:95)
at org.springframework.orm.jpa.AbstractEntityManagerFactoryBean.translateExceptionIfPossible(AbstractEntityManagerFactoryBean.java:306)
at org.springframework.dao.support.ChainedPersistenceExceptionTranslator.translateExceptionIfPossible(ChainedPersistenceExceptionTranslator.java:62)
at org.springframework.dao.support.DataAccessUtils.translateIfNecessary(DataAccessUtils.java:212)
at org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:146)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:631)
(...)
Name and version of the database you are using:
Oracle 10G

Umm, let me guess. I don't think DELETE_ORPHAN can do much in this case because the session object does not have the collection in memory so that it knows who is orphan now. You could possibly test this theory by adding a @org.hibernate.annotations.Entity and specifying selectBeforeUpdate. See if this makes any difference for you. If not, please give me the whole stack trace.


Farzad-



ADDED LATER: I did a test and it passed. Well, it means that the thing I said above has nothing to do with your problem. I am looking more into it.

I've been doing some tests, and I get it to work if I remove the DELETE_ORPHAN annotation, and merge the differences manually. That means whenever my EJB comes into my update() method, I must do a fetch for the original scenario object, and merge its dependencyElements collection by comparing each element and adding/removing as necessary.

What I would like is to do this automatically, but according to the lifecycle of an entity, I must always fetch the parent instance and handle this instance's collection so that hibernate can track the changes to the collection. Am I right, or can I do this transparently?

Removing DELETE_ORPHAN will sure hide the problem but it is still there. I have readnig hibernate code for this problem and it appears you have a collection in your hibernate session that is not traversed by reachability and that is the one that is causing the problem. You sure should not have a problem by creating an object tree and merging it into a session. This tells me that may be something else is also happening in scope of the same session or you are using an stale session somehow. However, I know so little about your code at this point and I can infer much. You could set hibernate logging to debug or trace and show me what it says. You could also debug the code and go into hibernate code. That will definitely tell you what's going wrong.



Farzad-

I believe the problem is because I'm setting a collection on a scenario that's unmanaged, and I can only do that with managed scenarios.

Im saying this:

If I do the following(pseudo code):


What I want is to hibernate change d1's name to "xx" with a sql update, insert a new one for d2, and remove any other dependencies if they exist.
I guess this doesn't work because my scenario has an unmanaged collection.

Nah, that is not your problem. I do this test which is exactly what you do but it passes:



It also detects what Widgets used to be in the Container and it removes them from database. Merge will cause a select from database if the object is not in the sessions first level cache. You could verify this by looking at the hibernate log. If you don't see a select then you might have a problem with equals and hashcode methods. Basically hibernate is not able to find the relation or you could be playing with references and that explains why there is a zombie collection in the session's first level cache.


Farzad-

I don't know if by calling you're passing the id of the widget (71) or it's just a property, but in my example the equivalent would be passing a widget without an id, besides the first one with the 71 in the constructor, and hibernate updating the first, persisting the second and deleting any other.

By the way, in your example do you use the "mappedBy" attribute in the @JoinColumn for WidgetContainer? and do you use the DELETE_ORPHAN hibernate annotation?

I'll check it out later and see what I'm doing wrong, anyway thanks for the quick reply!

It is indeed the id. I forgot to mention that. I was just too lazy to do it over and over and yes I do use DELETE_ORPHAN. I modified one of my examples to match your case. I also did a couple of other cases that would cause a WidgetContainer to be loaded into the session's memory and within the scope of the same session I created a WidgetContainer object with the same primary key and a modified list of Widgets, all new objects, and it worked and hibernate removed the Widgets that were not longer in the list.


Farzad-

Hi again, can you show your mapping for Widget and WidgetContainer?
Are you using the mappedBy property (equivalent to inverse=true)?

I've been reading the "Java persistence with hibernate" but I'm confused, because I've found on some forums that if you do not specify the "mappedBy" attribute, the parent becomes responsible for the relation. In the book it seems the other way.

Thanks again

There you go. I modified my example a little more so that it very much looks like your mapping and I still get the same results:







Umm, I don't know why you are concerned with that since I don't believe your problem is there. You should more be focused how you obtain an EntityManager and if it is shared with other areas of your code. You may also want to get a new entity manager in that part of your code and merge the changes with that.


Farzad-

Thanks, I solved it. I found out the hard way how simple it is.

I removed the "mappedBy" from parent annotations, added the "DELETE_ORPHAN" hibernate annotation, and most important, I only add/remove childs from managed instances. Among other things I was doing

instead of doing


The someMixedChildsSet can have childs with or without id.

I also had another problem, I had a parent-child-grandchild relation whose grandchilds were not properly mapped.

I understand that is unusual, but this way I can manage childs only from the parent entity.

Thanks again![/i]