[Hibernate-JIRA] Created: (HHH-3445) Single Table Inheritence Broken for non table-unique keys
by Todd Tidwell (JIRA)
Single Table Inheritence Broken for non table-unique keys
---------------------------------------------------------
Key: HHH-3445
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3445
Project: Hibernate3
Issue Type: Bug
Environment: Hibernate Core: 3.2.6.ga
Hibernate Annotations: 3.3.1.ga
Hibernate EntityManager: 3.3.2.ga
DB2 Linux 9.1
Reporter: Todd Tidwell
I have an interesting mapping case that is causing me some very odd low-level errors. In this particular case, I'm working with a table that contains multiple objects and I can use a DiscriminatorColumn to differentiate. However, the "primary key" for the child objects is not guaranteed to be uniqe table-wide. For example, DiscriminatorColumn value '013' may have a unique-key value of 'A', DiscriminatorColumn '014' may have the same unique-key value.
To map this, I created a base class, gave it the DiscriminatorColumn annotation, and then extended it with my various types.
Here are the classes:
@Entity
@Table(name="WTTBLE")
@DiscriminatorColumn(name="PTBLE")
public abstract class MetaData
{
@Id
@Basic(fetch=FetchType.EAGER)
@Column(name="PCODE", nullable=false, insertable=false, updatable=false)
private String code = null;
@Basic(fetch=FetchType.EAGER)
@Column(name="DEF", nullable=false, insertable=false, updatable=false)
private String value = null;
....
}
@Entity
@DiscriminatorValue(value = "015")
public class AddressType
extends MetaData
{
// No fields here, they're all mapped in MetaData
}
@Entity
@DiscriminatorValue(value = "016")
public class CustomerType
extends MetaData
{
// No fields here, they're all mapped in MetaData
}
Now, this works great until they both have the same value for the "code" property. At that point, I get the following logging and exception:
org.hibernate.impl.SessionImpl - initializing proxy: [com.wiley.permissions.domain.persistence.wintouch.metadata.AddressType#A]
....
org.hibernate.event.def.DefaultLoadEventListener - load request found matching entity in context, but the matched entity was of an inconsistent return type; returning null
....
javax.persistence.EntityNotFoundException: Unable to find test.AddressType with id A
at org.hibernate.ejb.Ejb3Configuration$Ejb3EntityNotFoundDelegate.handleEntityNotFound(Ejb3Configuration.java:107)
at org.hibernate.proxy.AbstractLazyInitializer.checkTargetState(AbstractLazyInitializer.java:79)
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:68)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.invoke(CGLIBLazyInitializer.java:150)
at test.AddressType$$EnhancerByCGLIB$$16d4c983.getValue(<generated>)
After some serious research, I found that org.hibernate.engine.StatefulPersistenceContext is returning the wrong object from it's getEntity method. It's returning a CustomerType object, which was added to the session's cache after the address type. On furthur examination, this seems to be because org.hibernate.engine.EntityKey.equals() is returning the same value for both objects. EntityKey's code for lines 95 -99 is:
public boolean equals(Object other) {
EntityKey otherKey = (EntityKey) other;
return otherKey.rootEntityName.equals(this.rootEntityName) &&
identifierType.isEqual(otherKey.identifier, this.identifier, entityMode, factory);
}
Examination of the values of EntityKey for my objects show that rootEntityName for both objects is test.MetaData. That means that this method is going to return true. That, in turn, means that StatefulPersistenceContext's entitiesByKey HashMap is going to return the first one that equals the one passed into the get() method.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[Hibernate-JIRA] Created: (HHH-3119) LazyInitializationException from 3.2.4+ onward
by Nick de Graeve (JIRA)
LazyInitializationException from 3.2.4+ onward
----------------------------------------------
Key: HHH-3119
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3119
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4
Reporter: Nick de Graeve
Priority: Blocker
We used to run JBoss 4.0.4.GA and we included Hibernate 3.2.0CR2 ourselves. Now we migrated to JBoss 4.2.2.GA and in that one Hibernate 3.2.4.sp1 is included by default.
Unfortunately, we're getting LazyInitializationException when the object graph is more than 2 levels deep.
E.g. RtTask --[OK]--> Priority --[FAIL]--> DictionaryEntry
We haven't changed anything to our beans or configuration files.
I did find out that v.3.2.4 is the first version that throws the exception.
Example stack trace:
2008-02-18 13:52:35,425 ERROR [org.hibernate.LazyInitializationException] could not initialize proxy - no Session
org.hibernate.LazyInitializationException: could not initialize proxy - no Session
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:57)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:166)
at com.fpc.nokeos.core.common.beans.persistent.Priority_$$_javassist_13.getEntryName(Priority_$$_javassist_13.java)
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 com.fpc.nokeos.core.server.dictionary.DictionaryContext.getField(DictionaryContext.java:319)
at com.fpc.nokeos.core.server.dictionary.DictionaryContext.preparePojoAfterGetting(DictionaryContext.java:276)
at com.fpc.nokeos.component.controlpanel.task.server.business.ControlPanelPluginTaskHelper.cleanRtTask(ControlPanelPluginTaskHelper.java:184)
at com.fpc.nokeos.component.controlpanel.task.server.business.ControlPanelPluginTaskHelper.executeQueryToGetCPItem(ControlPanelPluginTaskHelper.java:575)
at com.fpc.nokeos.component.controlpanel.task.server.business.ControlPanelPluginTaskHelper.getControlPanelItemsByFilter(ControlPanelPluginTaskHelper.java:525)
at com.fpc.nokeos.component.controlpanel.task.server.ejb.ControlPanelPluginTaskBean.getControlPanelItemsByFilter(ControlPanelPluginTaskBean.java:59)
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.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:166)
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:115)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
2008-02-18 13:52:35,534 ERROR [com.fpc.nokeos.core.server.dictionary.DictionaryContext] Could not get field 'NAME'.
java.lang.reflect.InvocationTargetException
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 com.fpc.nokeos.core.server.dictionary.DictionaryContext.getField(DictionaryContext.java:319)
at com.fpc.nokeos.core.server.dictionary.DictionaryContext.preparePojoAfterGetting(DictionaryContext.java:276)
at com.fpc.nokeos.component.controlpanel.task.server.business.ControlPanelPluginTaskHelper.cleanRtTask(ControlPanelPluginTaskHelper.java:184)
at com.fpc.nokeos.component.controlpanel.task.server.business.ControlPanelPluginTaskHelper.executeQueryToGetCPItem(ControlPanelPluginTaskHelper.java:575)
at com.fpc.nokeos.component.controlpanel.task.server.business.ControlPanelPluginTaskHelper.getControlPanelItemsByFilter(ControlPanelPluginTaskHelper.java:525)
at com.fpc.nokeos.component.controlpanel.task.server.ejb.ControlPanelPluginTaskBean.getControlPanelItemsByFilter(ControlPanelPluginTaskBean.java:59)
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.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:191)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:95)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:166)
at org.jboss.ejb3.security.RoleBasedAuthorizationInterceptor.invoke(RoleBasedAuthorizationInterceptor.java:115)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:77)
at org.jboss.ejb3.security.Ejb3AuthenticationInterceptor.invoke(Ejb3AuthenticationInterceptor.java:110)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:46)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:304)
at org.jboss.aop.Dispatcher.invoke(Dispatcher.java:106)
at org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:769)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:573)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:373)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:166)
Caused by: org.hibernate.LazyInitializationException: could not initialize proxy - no Session
at org.hibernate.proxy.AbstractLazyInitializer.initialize(AbstractLazyInitializer.java:57)
at org.hibernate.proxy.AbstractLazyInitializer.getImplementation(AbstractLazyInitializer.java:111)
at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:166)
at com.fpc.nokeos.core.common.beans.persistent.Priority_$$_javassist_13.getEntryName(Priority_$$_javassist_13.java)
... 46 more
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[Hibernate-JIRA] Created: (HHH-2498) Lazy Inverse Map Bug?
by CannonBall (JIRA)
Lazy Inverse Map Bug?
---------------------
Key: HHH-2498
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2498
Project: Hibernate3
Type: Bug
Versions: 3.2.1, 3.2.2
Environment: Hibernate 3.2.2, Java5, MySQL 5 (InnoDB)
Reporter: CannonBall
Priority: Minor
Mapping documents:
<hibernate-mapping>
<class name="scratchpad.hibernate.A">
<id name="id">
<generator class="assigned"/>
</id>
<map name="bs" cascade="all-delete-orphan" inverse="true">
<key column="aId"/>
<map-key type="long" column="cId"/>
<one-to-many class="scratchpad.hibernate.B"/>
</map>
</class>
<class name="scratchpad.hibernate.B">
<id name="id">
<generator class="assigned"/>
</id>
<many-to-one name="a" class="scratchpad.hibernate.A" column="aId"/>
<many-to-one name="c" class="scratchpad.hibernate.C" column="cId" not-null="true"/>
</class>
<class name="scratchpad.hibernate.C">
<id name="id">
<generator class="assigned"/>
</id>
</class>
</hibernate-mapping>
Code between sessionFactory.openSession() and session.close():
long aId = 1l;
long bId = 2l;
long cId = 3l;
SessionFactory factory = new Configuration().configure()
.buildSessionFactory();
try {
Session s = factory.openSession();
try {
Transaction tx = s.beginTransaction();
try {
C c = new C(cId);
s.save(c);
A a = new A(aId);
B b = new B(bId);
b.setC(c);
b.setA(a);
a.getBs().put(cId, b);
s.save(a);
tx.commit();
} catch (Exception e) {
try {
tx.rollback();
} catch (Exception e2) {
// do nothing
}
throw e;
}
} finally {
s.close();
}
s = factory.openSession();
try {
Transaction tx = s.beginTransaction();
try {
A a = (A) s.load(A.class, aId);
a.getBs().remove(cId);
tx.commit();
} catch (Exception e) {
try {
tx.rollback();
} catch (Exception e2) {
// do nothing
}
throw e;
}
} finally {
s.close();
}
} finally {
factory.close();
}
Name and version of the database you are using: MySQL 5.0.33
The generated SQL (show_sql=true):
Hibernate: select b_.id, b_.aId as aId1_, b_.cId as cId1_ from B b_ where b_.id=?
Hibernate: insert into C (id) values (?)
Hibernate: insert into A (id) values (?)
Hibernate: insert into B (aId, cId, id) values (?, ?, ?)
Hibernate: select a0_.id as id0_0_ from A a0_ where a0_.id=?
Hibernate: select bs0_.aId as aId1_, bs0_.id as id1_, bs0_.cId as cId1_, bs0_.id as id1_0_, bs0_.aId as aId1_0_, bs0_.cId as cId1_0_ from B bs0_ where bs0_.aId=?
I've been having a confusing problem shown above, whereby A has a Map of Bs indexed using the id from an association with C. This Map is inversely mapped for A and with 'Cascade Delete Orphan'. In the second opened session above, where B is removed from A's Map and thus orphaned, B will not be deleted. I have observed B is only deleted if I either set 'lazy="false"' for A's Map or make an interaction with A's Map in the code (before B's removal) like 'a.getBs().get(cId)'. I suspect the lazy intializer is not initializing correctly in the above scenario.
The above scenario does not happen if A's Map is not inversely mapped but B's many-to-one with A is.
Can somebody shed some light on whether this is me using Hibernate incorrectly or is a bug?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
15 years, 3 months
[Hibernate-JIRA] Created: (HHH-3504) Hibernate 3.3.1GA issue when using CGLIB
by Montagnon Cyril (JIRA)
Hibernate 3.3.1GA issue when using CGLIB
----------------------------------------
Key: HHH-3504
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3504
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: Database : hsqldb/Sybase
Reporter: Montagnon Cyril
When forcing hibernate to use CGLIB (by the way javassist is still slower than CGLib), I get the following exception (at the end of the post)
It seems that the repackaging of the CGLIB project (hibernate-cglib-repack) doesn't behave as expected :
Shouldn't it look up for the org.hibernate.repackage.cglib.proxy.Callback class instead of the net.sf.cglib.proxy.Callback class.
java.lang.NoClassDefFoundError: net.sf.cglib.proxy.Callback
at org.hibernate.repackage.cglib.proxy.Enhancer.class$(Enhancer.java:68)
at org.hibernate.repackage.cglib.proxy.Enhancer.getCallbacksSetter(Enhancer.java:627)
at org.hibernate.repackage.cglib.proxy.Enhancer.setCallbacksHelper(Enhancer.java:615)
at org.hibernate.repackage.cglib.proxy.Enhancer.setThreadCallbacks(Enhancer.java:609)
at org.hibernate.repackage.cglib.proxy.Enhancer.registerCallbacks(Enhancer.java:578)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyInstance(CGLIBLazyInitializer.java:133)
at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxy(CGLIBLazyInitializer.java:116)
at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.getProxy(CGLIBProxyFactory.java:72)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.createProxy(AbstractEntityTuplizer.java:402)
at org.hibernate.persister.entity.AbstractEntityPersister.createProxy(AbstractEntityPersister.java:3483)
at org.hibernate.event.def.DefaultLoadEventListener.createProxyIfNecessary(DefaultLoadEventListener.java:298)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:219)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:126)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:905)
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:822)
at org.hibernate.impl.SessionImpl.load(SessionImpl.java:815)
at org.springframework.orm.hibernate3.HibernateTemplate$3.doInHibernate(HibernateTemplate.java:566)
at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419)
at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374)
at org.springframework.orm.hibernate3.HibernateTemplate.load(HibernateTemplate.java:560)
at org.springframework.orm.hibernate3.HibernateTemplate.load(HibernateTemplate.java:554)
at north.stardust2.core.test.unit.dao.listed.IndexCompositionDaoTest.findIndexCompositionByListedIndexAt(IndexCompositionDaoTest.java:36)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.junit.internal.runners.CompositeRunner.runChildren(CompositeRunner.java:33)
at org.junit.runners.Suite.access$000(Suite.java:26)
at org.junit.runners.Suite$1.run(Suite.java:93)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.runners.Suite.run(Suite.java:91)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[Hibernate-JIRA] Created: (HHH-3523) org.hibernate.id.enhanced.SequenceStyleGenerator causes org.hibernate.MappingException with SAPDB and DB2Dialect
by Damir Malenicic (JIRA)
org.hibernate.id.enhanced.SequenceStyleGenerator causes org.hibernate.MappingException with SAPDB and DB2Dialect
----------------------------------------------------------------------------------------------------------------
Key: HHH-3523
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3523
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1.GA
Generation of DDL scripts for DB2Dialect and SAPDBDialect
Reporter: Damir Malenicic
Attachments: db2-sapdb-bug.zip
While generating DDL scripts for mapping files that declare id <generator class="org.hibernate.id.enhanced.SequenceStyleGenerator"> the following exception is thrown:
org.hibernate.MappingException: Dialect does not support pooled sequences
at org.hibernate.dialect.Dialect.getCreateSequenceString(Dialect.java:701)
at org.hibernate.dialect.Dialect.getCreateSequenceStrings(Dialect.java:659)
at org.hibernate.id.enhanced.SequenceStructure.sqlCreateStrings(SequenceStructure.java:139)
at org.hibernate.id.enhanced.SequenceStyleGenerator.sqlCreateStrings(SequenceStyleGenerator.java:328)
at org.hibernate.cfg.Configuration.generateSchemaCreationScript(Configuration.java:945)
at org.hibernate.tool.hbm2ddl.SchemaExport.<init>(SchemaExport.java:129)
at org.hibernate.tool.hbm2ddl.SchemaExport.<init>(SchemaExport.java:91)
I suspect the cause is in
org.hibernate.dialect.Dialect#getCreateSequenceString(String sequenceName, int initialValue, int incrementSize)
if ( supportsPooledSequences() ) {
return getCreateSequenceString( sequenceName ) + " start with " + initialValue + " increment by " + incrementSize;
}
throw new MappingException( "Dialect does not support pooled sequences" );
This call requires not just that dialect supports sequences but that dialect supports pooled sequences.
But the algorithm that tries to determine whether the table should be used to emulate the sequence lets the dialects that supports sequences but not pooled sequences to slip through. It looks like the DB2 and SAPDB dialects fail in this category because of:
org.hibernate.id.enhanced.SequenceStyleGenerator#configure(Type type, Properties params, Dialect dialect)
...
if ( dialect.supportsSequences() && !forceTableUse ) {
if ( OptimizerFactory.POOL.equals( optimizationStrategy ) && !dialect.supportsPooledSequences() ) {
forceTableUse = true;
log.info(
"Forcing table use for sequence-style generator due to pooled optimizer selection where db does not support pooled sequences"
);
}
}
To workaround the problem I have created my generator that overrides SequenceStyleGenerator#configure, somethng like:
public void configure(Type type, Properties params, Dialect dialect) throws MappingException {
if (dialect.supportsSequences() && !dialect.supportsPooledSequences()) {
params.setProperty(FORCE_TBL_PARAM, "true");
}
super.configure(type, params, dialect);
Attached is a zip file with a small maven project with unit-test that replicates the problem. It generates DDL for different databases: Hipersonic, Derby, Oracle, MySql, PostgreSQL, MSSQL, DB2, and SAPDB. The data-model contains 2 tables Person and Event in many-to-many relation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months
[Hibernate-JIRA] Created: (HHH-2881) PersistantBag.initializeFromCache can be intercepted by CollectionLoadContext.getLoadingCollection and so corrupt the collection
by Pavol Zibrita (JIRA)
PersistantBag.initializeFromCache can be intercepted by CollectionLoadContext.getLoadingCollection and so corrupt the collection
--------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2881
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2881
Project: Hibernate3
Issue Type: Bug
Environment: Hibernate Entity Manager 3.3.1 GA, oracle,
Reporter: Pavol Zibrita
It can occur that while PersistenBag.initializeFromCache is called to populate the collection from cache, the collection is populated also from CollectionLoadContext.getLoadingCollection, and so, the collection is filled with more data than needed. As the initializeFromCache uses direct access to the property this.bag, it will continue loading the collection. Here is the stack trace of what happens:
PersistentBag.beforeInitialize(CollectionPersister, int) line: xx //here is the same collection reinitialized again, and loaded again
CollectionLoadContext.getLoadingCollection(CollectionPersister, Serializable) line: 127
EntityLoader(Loader).readCollectionElement(Object, Serializable, CollectionPersister, CollectionAliases, ResultSet, SessionImplementor) line: 1003
EntityLoader(Loader).readCollectionElements(Object[], ResultSet, SessionImplementor) line: 646
EntityLoader(Loader).getRowFromResultSet(ResultSet, SessionImplementor, QueryParameters, LockMode[], EntityKey, List, EntityKey[], boolean) line: 591
EntityLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 701
EntityLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 236
EntityLoader(Loader).loadEntity(SessionImplementor, Object, Type, Object, String, Serializable, EntityPersister) line: 1860
EntityLoader(AbstractEntityLoader).load(SessionImplementor, Object, Object, Serializable) line: 48
EntityLoader(AbstractEntityLoader).load(Serializable, Object, SessionImplementor) line: 42
SingleTableEntityPersister(AbstractEntityPersister).load(Serializable, Object, LockMode, SessionImplementor) line: 3044
DefaultLoadEventListener.loadFromDatasource(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 395
DefaultLoadEventListener.doLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 375
DefaultLoadEventListener.load(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 139
DefaultLoadEventListener.proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 195
DefaultLoadEventListener.onLoad(LoadEvent, LoadEventListener$LoadType) line: 103
SessionImpl.fireLoad(LoadEvent, LoadEventListener$LoadType) line: 878
SessionImpl.internalLoad(String, Serializable, boolean, boolean) line: 846
ManyToOneType(EntityType).resolveIdentifier(Serializable, SessionImplementor) line: 557
ManyToOneType.assemble(Serializable, SessionImplementor, Object) line: 196
TypeFactory.assemble(Serializable[], Type[], SessionImplementor, Object) line: 420
CacheEntry.assemble(Serializable[], Object, Serializable, EntityPersister, Interceptor, EventSource) line: 96
CacheEntry.assemble(Object, Serializable, EntityPersister, Interceptor, EventSource) line: 82
DefaultLoadEventListener.assembleCacheEntry(CacheEntry, Serializable, EntityPersister, LoadEvent) line: 553
DefaultLoadEventListener.loadFromSecondLevelCache(LoadEvent, EntityPersister, LoadEventListener$LoadType) line: 508
DefaultLoadEventListener.doLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 357
DefaultLoadEventListener.load(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 139
DefaultLoadEventListener.proxyOrLoad(LoadEvent, EntityPersister, EntityKey, LoadEventListener$LoadType) line: 195
DefaultLoadEventListener.onLoad(LoadEvent, LoadEventListener$LoadType) line: 103
SessionImpl.fireLoad(LoadEvent, LoadEventListener$LoadType) line: 878
SessionImpl.internalLoad(String, Serializable, boolean, boolean) line: 846
ManyToOneType(EntityType).resolveIdentifier(Serializable, SessionImplementor) line: 557
ManyToOneType.assemble(Serializable, SessionImplementor, Object) line: 196
PersistentBag.initializeFromCache(CollectionPersister, Serializable, Object) line: xxx //NOW HERE IS THE Bag initializing from cache, it fails, see top of the stack!!
CollectionCacheEntry.assemble(PersistentCollection, CollectionPersister, Object) line: 35
DefaultInitializeCollectionEventListener.initializeCollectionFromCache(Serializable, CollectionPersister, PersistentCollection, SessionImplementor) line: 130
DefaultInitializeCollectionEventListener.onInitializeCollection(InitializeCollectionEvent) line: 48
SessionImpl.initializeCollection(PersistentCollection, boolean) line: 1716
PersistentBag(AbstractPersistentCollection).forceInitialization() line: 454
StatefulPersistenceContext.initializeNonLazyCollections() line: 794
QueryLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 241
QueryLoader(Loader).doList(SessionImplementor, QueryParameters) line: 2220
QueryLoader(Loader).listIgnoreQueryCache(SessionImplementor, QueryParameters) line: 2104
QueryLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type[]) line: 2099
QueryLoader.list(SessionImplementor, QueryParameters) line: 378
QueryTranslatorImpl.list(SessionImplementor, QueryParameters) line: 338
HQLQueryPlan.performList(QueryParameters, SessionImplementor) line: 172
SessionImpl.list(String, QueryParameters) line: 1121
QueryImpl.list() line: 79
QueryImpl.getResultList() line: 66
//some stack before, uninportant
Small fix to the PersistantBag has resolved this issue, however I cannot tell if it is correct by some hibernate principles:
public void initializeFromCache(CollectionPersister persister, Serializable disassembled, Object owner)
throws HibernateException {
Serializable[] array = (Serializable[]) disassembled;
int size = array.length;
List<Object> elements = new ArrayList<Object>(size);
for ( int i = 0; i < size; i++ ) {
Object element = persister.getElementType().assemble( array[i], getSession(), owner );
if ( element!=null ) {
elements.add( element );
}
}
beforeInitialize( persister, size );
for ( Object element : elements ) {
this.bag.add( element );
}
}
Difference is, before the this.bag.add(element) was called in first cycle, where the line of getting the element could cause reinitializing the collection and filling it up. There are various possibilities how to fix the problem, but I don't know if the fix is at the right place!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 3 months