I got the same error deploying to 4.0.4.GA. In my case I had an entity bean with 2 fields annotated with
so I changed them both to read
and now the .ear file deploys without errors. I added the FetchType.EAGER a while back because FetchType.LAZY didn't seem to work even after calling size() or something, so I'll have to re-test that now.
http://forum.hibernate.org/viewtopic.php?t=948156&highlight=fetch+bags+multiple This is a post in the hibernate forums that might help also.
that changed line should read
with the @.
Yes, thanks a lot!
As you said, the new Hibernate version seems to have a bug with OneToMany relations when they are fetched eager.
OneToOne, ManyToOne and ManyToMany relations still work fine with eager fetch type. Every single OneToMany relation, which is declared with fetch type eager crashes the deployment of my application.
Just to let you know,
This is not a bug.
Could you please explain what the best solution is for this problem. I don't want to lazyload all my oneToMany relationships
List with an explicit @IndexColumn
rather than a bag semantic collection like Collection.
I usually make sense for 99% of the domain models
Thank you for the tip, I used the @IndexColumn.
Because I needed a list and I already had a JBoss depency(CascadeType.DELETE_ORPHAN)
I don't find @IndexColum in Java EE API.
I need to fetch eager and use List for @OneToMany.
@IndexColumn never existed in Java EE API. It is a hibernate annotations thing.
Whenever I used @IndexColumn, the first value of the Persistent list is always null. refer to my "is this a bug?" post.
I'm getting the same error on deployment, but it appears to be in my EJBQL Named Queries. Is there any way to isolate specifically which named queries have the problem? Any log messages I can look for? It will take considerable effort to dig through all of them. I use JOIN FETCH and LEFT OUTER JOIN FETCH extensively in my EJBQL.
FWIW, I'm upgrading from CR1 (or RC1?) to GA. I don't think pasting my persistence.xml or listing all my EJBQL will help, but here's the snippet from the stack trace that makes me think the issue is in my named queries:
17:07:31,563 WARN [ServiceController] Problem starting service persistence.units:unitName=MyEntityManager org.hibernate.HibernateException: cannot simultaneously fetch multiple bags at org.hibernate.loader.BasicLoader.postInstantiate(BasicLoader.java:66) at org.hibernate.loader.hql.QueryLoader.<init>(QueryLoader.java:100) at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:180) at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:110) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:77) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:56) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:71) at org.hibernate.impl.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:397) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:348) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:631) at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:760) at org.hibernate.ejb.Ejb3Configuration.createContainerEntityManagerFactory(Ejb3Configuration.java:350) at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:119) at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.ejb3.ServiceDelegateWrapper.startService(ServiceDelegateWrapper.java:99) at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289) at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978) at $Proxy0.start(Unknown Source) at org.jboss.system.ServiceController.start(ServiceController.java:417)
I still got the same error after adding @IndexColumn(name="id") under @OneToMany(...).
Do I need to do the same for @ManyToOne and @ManyToMany?
I think the answer is the same for all of us -- don't use List, unless you have a really good reason. Use SortedSet.
Then you can use @Sort(type=SortType.NATURAL) if you have Comparable implemented, make your own Comparator, or leave it unsorted. I'm assuming that like me, you only used List because you cared about the order. If using SortedSet typed collections, there's no need for @IndexColumn to resolve this error because you won't be using bags.
I hope some of this looks familiar, and this resolves your issue as it did mine. Thanks, Emmanuel, for your insight.
I have a problem after changing List to Set. Since the data type of JSF dataTable should be List, Array or ResultSet, it is a little hard to change Set back to List to be displayed by dataTable, especially for Seam @DataModel. Anybody has some good idea? Thank you.