[Hibernate-JIRA] Closed: (HHH-1318) result of an imbed collection are dropped
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1318?page=c... ]
Steve Ebersole closed HHH-1318.
-------------------------------
Closing stale resolved issues
> result of an imbed collection are dropped
> -----------------------------------------
>
> Key: HHH-1318
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1318
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.1
> Environment: Tomcate 5.28 using sql 2003
> Reporter: walter barnie
> Attachments: Hibernate.zip
>
>
> Walter Barnie
> 23 December 2005
> Environment
> Hibernate release 3.0
> Spring Framework 1.2
> JDTS release1.0.2
> Microsoft SQL server 2003
> Java jdk1.5.0_03
> Files
> PickListProducts.java - interface to product POJO
> PickListProductsPOJO.java product POJO
> PickListProductsUID.java - product unique id
> PickListInventory.java - inventory interface
> PickListInventoryPOJO.java - inventory POJO
> PickListInventoryUID.java - inventory unique id
> pickList.jsp - jsp page
> PickList.hbm.xml hibernate mapping file. The table, view is PickListProductsPOJO, which has a bag pickListInventory
> stdout.log - tomcat log
> Problem
> Hibernate appears to be dropping records. We have a view of products that has an imbedded collection of corresponding inventory. Using a profiler, we can see the query being issued and the data is coming back as expected, however, the collection is empty. Going though the log, it appears that all the corresponding items have been return and there are entries that the appropriate collections have been hydrated with the number we expect.
> Product MOA-LJE-K 2 associated inventory items: GVELH12RMOALIBG and EVEL12ROUT
> Product MOA-LGC-F has 1 inventory item GVELH12FMOALGCF
> If there is anything else I can provide you with please let me know. I can be reach by email: wbarnie(a)checkernet.com or phone (508) 438-2179. Thank you for your help.
--
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, 1 month
[Hibernate-JIRA] Closed: (HHH-1328) org.hibernate.util.SimpleMRUCache keeps a soft reference to the cache key, so cached values get collected prematurely
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1328?page=c... ]
Steve Ebersole closed HHH-1328.
-------------------------------
Closing stale resolved issues
> org.hibernate.util.SimpleMRUCache keeps a soft reference to the cache key, so cached values get collected prematurely
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1328
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1328
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Environment: Hibernate 3.1. I believe this hasn't changed in CVS.
> Reporter: Tzvetan Mikov
> Assignee: Steve Ebersole
> Priority: Minor
> Fix For: 3.1.1
>
>
> org.hibernate.util.SimpleMRUCache uses org.apache.commons.collections.ReferenceMap to map HQLQueryPlanKey to HQLQueryPlan. However both the value and the key are stored with soft references. The last 128 HQLQueryPlan-s are kept in a strong reference array, but the cache keys aren't, so often cache entries cannot be found, even though the values still exist in memory.
> There is a comment in the source saying:
> // both keys and values may be soft since value keeps a hard ref to the key (and there is a hard ref to MRU values)
> but it isn't actually true since the value (HQLQueryPlan) doesn't actually keep a reference to the key (HQLQueryPlanKey).
> This is a simplistic patch that should fix the problem:
> --- SimpleMRUCache.java 2005-12-12 07:03:46.000000000 -0800
> +++ SimpleMRUCache-new.java 2005-12-28 18:34:09.920112661 -0800
> @@ -16,20 +16,24 @@
>
> private static final int MAX_STRONG_REF_COUNT = 128; //TODO: configurable?
> private final transient Object[] strongRefs = new Object[MAX_STRONG_REF_COUNT]; //strong reference to MRU queries
> + private final transient Object[] strongKeyRefs = new Object[MAX_STRONG_REF_COUNT];
> private transient int strongRefIndex = 0;
> private final transient Map softQueryCache = new ReferenceMap(ReferenceMap.SOFT, ReferenceMap.SOFT) ;
> - // both keys and values may be soft since value keeps a hard ref to the key (and there is a hard ref to MRU values)
>
> public synchronized Object get(Object key) {
> Object result = softQueryCache.get( key );
> if( result != null ) {
> - strongRefs[ ++strongRefIndex % MAX_STRONG_REF_COUNT ] = result;
> + ++strongRefIndex;
> + strongRefs[ strongRefIndex % MAX_STRONG_REF_COUNT ] = result;
> + strongKeyRefs[ strongRefIndex % MAX_STRONG_REF_COUNT ] = key;
> }
> return result;
> }
>
> public void put(Object key, Object value) {
> softQueryCache.put( key, value );
> - strongRefs[ ++strongRefIndex % MAX_STRONG_REF_COUNT ] = value;
> + ++strongRefIndex;
> + strongRefs[ strongRefIndex % MAX_STRONG_REF_COUNT ] = value;
> + strongKeyRefs[ strongRefIndex % MAX_STRONG_REF_COUNT ] = key;
> }
> }
--
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, 1 month
[Hibernate-JIRA] Closed: (HHH-1064) Exception using JTATransaction in WebSphere 6
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1064?page=c... ]
Steve Ebersole closed HHH-1064.
-------------------------------
Closing stale resolved issues
> Exception using JTATransaction in WebSphere 6
> ---------------------------------------------
>
> Key: HHH-1064
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1064
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5, 3.1b3, IBM WebSphere 6 AS, Spring 1.2.5
> Reporter: Andrey Grebnev
> Assignee: Gavin King
> Fix For: 3.1 rc3
>
>
> I have already posted this bug to you http://opensource2.atlassian.com/projects/hibernate/browse/HHH-1053 but you rejected it. Now I concrete it according discussion in forum http://forum.hibernate.org/viewtopic.php?t=948460
> I am porting my application AtLeap (https://atleap.dev.java.net) from Hibernate 2.1.8 and Spring 1.1.5 to Hibernate 3.0.5 and Spring 1.2.5.
> AtLeap was working correctly under IBM WebSphere 6 AS with following settings:
> <property name="hibernate.transaction.factory_class" value="org.hibernate.transaction.JTATransactionFactory"/>
> <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.WebSphereTransactionManagerLookup"/>
>
> However when I have ported AtLeap into Hibernate 3.0.5 and Spring 1.2.5 I have the following error:
> [05.10.05 22:12:06:531 GEST] 00000058 Helpers W NMSV0605W: A Reference object looked up from the context
> "agrebnevNode01Cell/nodes/agrebnevNode01/servers/server1" with the name "jta/usertransaction" was sent to the JNDI Naming Manager and an exception resulted. Reference data follows:
> Reference Factory Class Name: com.ibm.ws.Transaction.JTA.UtxJNDIFactory
> Reference Factory Class Location URLs: <null>
> Reference Class Name: java.lang.Object
> Exception data follows:
> javax.naming.ConfigurationException
> at com.ibm.ws.Transaction.JTA.UtxJNDIFactory.getObjectInstance(UtxJNDIFactory.java:107)
> at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:314)
> at com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookupExt(Helpers.java:874)
> at com.ibm.ws.naming.util.Helpers.processSerializedObjectForLookup(Helpers.java:681)
> at com.ibm.ws.naming.jndicos.CNContextImpl.cacheLookup(CNContextImpl.java:3489)
> at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1755)
> at com.ibm.ws.naming.jndicos.CNContextImpl.doLookup(CNContextImpl.java:1737)
> at com.ibm.ws.naming.jndicos.CNContextImpl.lookupExt(CNContextImpl.java:1444)
> at com.ibm.ws.naming.jndicos.CNContextImpl.lookup(CNContextImpl.java:1324)
> at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:144)
> at javax.naming.InitialContext.lookup(InitialContext.java:361)
> at org.hibernate.transaction.JTATransaction.begin(JTATransaction.java:58)
> at org.hibernate.transaction.JTATransactionFactory.beginTransaction(JTATransactionFactory.java:53)
> at org.hibernate.jdbc.JDBCContext.beginTransaction(JDBCContext.java:271)
> at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1079)
> at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:42
> 6)
> at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatform
> TransactionManager.java:281)
> at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(Transact
> ionAspectSupport.java:217)
> at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:89)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:144)
> at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:174)
> at $Proxy72.findContentPageByUri(Unknown Source)
> Many changes were done in org.hibernate.transaction.JTATransaction and org.hibernate.transaction.JTATransactionFactory in version 3.0.5 comparing with 2.1.8. Please look at the following code from JTATransactionFactory
> utName = props.getProperty(Environment.USER_TRANSACTION);
>
> if (utName==null) {
> TransactionManagerLookup lookup = TransactionManagerLookupFactory.getTransactionManagerLookup(props);
> if (lookup!=null) utName = lookup.getUserTransactionName();
> }
> if (utName==null) utName = DEFAULT_USER_TRANSACTION_NAME;
> We can see that we call getUserTransactionName
> Now let's look at WebSphereTransactionManagerLookup
> public String getUserTransactionName() {
> return version==5 ?
> "java:comp/UserTransaction":
> "jta/usertransaction";
> }
> the version variable will be initialized only after calling getTransactionManager, but we do not do it. As result we have utName equals jta/usertransaction, but it should be java:comp/UserTransaction
> --
> Andrey Grebnev
> http://www.jroller.com/page/agrebnev
--
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, 1 month
[Hibernate-JIRA] Closed: (HHH-535) properties element causes exception in interface/abstract class
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-535?page=co... ]
Steve Ebersole closed HHH-535.
------------------------------
Closing stale resolved issues
> properties element causes exception in interface/abstract class
> ---------------------------------------------------------------
>
> Key: HHH-535
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-535
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.3
> Environment: Hibernate version: 3.0.3
> Reporter: Jason Boutwell
> Assignee: Steve Ebersole
> Fix For: 3.2.0.alpha2, 3.1.3
>
>
> I am using the <properties> element to map some legacy data. It appears that Hibernate is trying to create a component POJO for the <properties> element with the type of the enclosing class, which is an interface. Is this expected behavior?
> <hibernate-mapping>
> <class name="Address" table="ADDRESS" proxy="Address">
> <meta attribute="interface" inherit="false">true</meta>
> <id name="addressId" type="long" column="ADDRESS_ID"/>
> <discriminator column="ADDRESS_TYPE" type="string" length="30" />
> <properties name="uniqueAddress">
> <property name="addressType" column="ADDRESS_TYPE" type="string" insert="false" update="false" length="30" />
> <many-to-one name="server" column="SERVER_ID" class="Server" not-null="true" />
> </properties>
> <subclass name="AddressImpl" discriminator-value="null" proxy="Address">
> </subclass>
> </class>
> <class name="Server" table="SERVER"
> proxy="Server">
> <meta attribute="interface"
> inherit="false">true</meta>
> <id name="serverId" type="long"
> column="SERVER_ID">
> <discriminator column="SERVER_TYPE"
> type="string" length="10"/>
> <property name="serverType" type="string"
> column="SERVER_TYPE" length="10"
> update="false" insert="false"/>
> <subclass name="ServerImpl"
> discriminator-value="null"
> proxy="Server">
> <many-to-one name="address"
> class="AddressImpl"
> property-ref="uniqueAddress"
> cascade="all-delete-orphan"
> unique="true"
> update="false" insert="false">
> <column name="ADDRESS_TYPE"/>
> <column name="SERVER_ID"/>
> </many-to-one>
> </subclass>
> </class>
> </hibernate-mapping>
> When I create a new Server and add a ServerAddress, Hibernate throws an Exception during the cascade, It seems to be trying to instantiate the <properties> "component":
> org.hibernate.InstantiationException: Cannot instantiate abstract class or interface: Address
> org.springframework.orm.hibernate3.HibernateSystemException: Cannot instantiate abstract class or interface: Address; nested exception is org.hibernate.InstantiationException: Cannot instantiate abstract class or interface: Addressorg.hibernate.InstantiationException: Cannot instantiate abstract class or interface: Address at org.hibernate.tuple.PojoInstantiator.instantiate(PojoInstantiator.java:56) at org.hibernate.tuple.AbstractComponentTuplizer.instantiate(AbstractComponentTuplizer.java:89) at org.hibernate.type.ComponentType.instantiate(ComponentType.java:344) at org.hibernate.type.ComponentType.deepCopy(ComponentType.java:301) at org.hibernate.type.TypeFactory.deepCopy(TypeFactory.java:290) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:226) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:159) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:184) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:173) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:96) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:69) at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:464) at org.hibernate.engine.Cascades$5.cascade(Cascades.java:154) at org.hibernate.engine.Cascades.cascadeAssociation(Cascades.java:771) at org.hibernate.engine.Cascades.cascade(Cascades.java:720) at org.hibernate.engine.Cascades.cascade(Cascades.java:847) at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:331) at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:213) at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:159) at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:107) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:184) at org.hibernate.event.def.DefaultSaveEventListener.saveWithGeneratedOrRequestedId(DefaultSaveEventListener.java:33) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:173) at org.hibernate.event.def.DefaultSaveEventListener.performSaveOrUpdate(DefaultSaveEventListener.java:27) at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:69) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:477) at org.hibernate.impl.SessionImpl.save(SessionImpl.java:472)
> According to Hibernate DEBUG logs, everything looks to be working until it tries to cascade save the AddressImpl, and it rolls back.
> 2005-05-24 18:27:31,183 DEBUG engine.PersistenceContext - initializing non-lazy collections
> 2005-05-24 18:27:31,190 DEBUG def.DefaultSaveOrUpdateEventListener - saving transient instance
> 2005-05-24 18:27:31,193 DEBUG jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
> 2005-05-24 18:27:31,194 DEBUG jdbc.AbstractBatcher - select SERVER_INFO_SEQ.nextval from dual
> 2005-05-24 18:27:31,195 DEBUG jdbc.AbstractBatcher - preparing statement
> 2005-05-24 18:27:31,237 DEBUG id.SequenceGenerator - Sequence identifier generated: 203783
> 2005-05-24 18:27:31,237 DEBUG jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> 2005-05-24 18:27:31,240 DEBUG jdbc.AbstractBatcher - closing statement
> 2005-05-24 18:27:31,241 DEBUG def.AbstractSaveEventListener - generated identifier: 203783, using strategy: org.hibernate.id.SequenceGenerator
> 2005-05-24 18:27:31,244 DEBUG def.AbstractSaveEventListener - saving [ServerImpl#203783]
> 2005-05-24 18:27:31,248 DEBUG engine.Cascades - processing cascade ACTION_SAVE_UPDATE for: ServerImpl
> 2005-05-24 18:27:31,249 DEBUG engine.Cascades$5 - cascading to saveOrUpdate: AddressImpl
> 2005-05-24 18:27:31,254 DEBUG def.AbstractSaveEventListener - transient instance of: AddressImpl
> 2005-05-24 18:27:31,255 DEBUG def.DefaultSaveOrUpdateEventListener - saving transient instance
> 2005-05-24 18:27:31,255 DEBUG jdbc.AbstractBatcher - about to open PreparedStatement (open PreparedStatements: 0, globally: 0)
> 2005-05-24 18:27:31,256 DEBUG jdbc.AbstractBatcher - select SERVER_ADDRESS_SEQ.nextval from dual
> 2005-05-24 18:27:31,257 DEBUG jdbc.AbstractBatcher - preparing statement
> 2005-05-24 18:27:31,264 DEBUG id.SequenceGenerator - Sequence identifier generated: 2007899
> 2005-05-24 18:27:31,266 DEBUG jdbc.AbstractBatcher - about to close PreparedStatement (open PreparedStatements: 1, globally: 1)
> 2005-05-24 18:27:31,267 DEBUG jdbc.AbstractBatcher - closing statement
> 2005-05-24 18:27:31,268 DEBUG def.AbstractSaveEventListener - generated identifier: 2007899, using strategy: org.hibernate.id.SequenceGenerator
> 2005-05-24 18:27:31,269 DEBUG def.AbstractSaveEventListener - saving [AddressImpl#2007899]
> 2005-05-24 18:27:31,282 DEBUG transaction.JDBCTransaction - rollback
> 2005-05-24 18:27:31,282 DEBUG jdbc.JDBCContext - before transaction completion
> 2005-05-24 18:27:31,283 DEBUG impl.SessionImpl - before transaction completion
> 2005-05-24 18:27:31,284 DEBUG transaction.JDBCTransaction - re-enabling autocommit
> 2005-05-24 18:27:31,285 DEBUG transaction.JDBCTransaction - rolled back JDBC Connection
> 2005-05-24 18:27:31,286 DEBUG jdbc.JDBCContext - after transaction completion
> 2005-05-24 18:27:31,286 DEBUG impl.SessionImpl - after transaction completion
> 2005-05-24 18:27:31,292 DEBUG impl.SessionImpl - closing session
> 2005-05-24 18:27:31,292 DEBUG jdbc.AbstractBatcher - closing JDBC connection (open PreparedStatements: 0, globally: 0) (open ResultSets: 0, globally: 0)
> 2005-05-24 18:27:31,297 DEBUG jdbc.JDBCContext - after transaction completion
> 2005-05-24 18:27:31,297 DEBUG impl.SessionImpl - after transaction completion
--
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, 1 month
[Hibernate-JIRA] Closed: (HHH-667) using joined-subclass in EntityMode.DOM4J causes org.hibernate.HibernateException: instance not of expected entity type:
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-667?page=co... ]
Steve Ebersole closed HHH-667.
------------------------------
Closing stale resolved issues
> using joined-subclass in EntityMode.DOM4J causes org.hibernate.HibernateException: instance not of expected entity type:
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-667
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-667
> Project: Hibernate Core
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.0.5
> Environment: hibernate 3.0.5 released and stream code
> Reporter: Jessica Marchiori
> Assignee: Steve Ebersole
>
> with that mapping
> <class name="com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PBreakdownItem" proxy="com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PBreakdownItem" table="PBreakdownItem" node="com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PBreakdownItem">
>
> <composite-id>
>
> <key-property name="oid$" length="35" node="@oid"/>
>
> </composite-id>
>
> <property name="itemDescription" type="string" node="itemDescription">
>
> <column name="itemDescription" length="128"/>
> </property>
>
> <property name="itemPergentage" type="big_decimal" node="itemPergentage">
>
> <column name="itemPergentage" length="4"/>
> </property>
>
> <joined-subclass name="com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PAssetTypeBI" proxy="com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PAssetTypeBI" table="PAssetTypeBI" node="com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PAssetTypeBI">
>
> <key>
>
> <column name="ownItem__oid$_fk" length="35"/>
> </key>
>
> <many-to-one name="passettype" embed-xml="false" node="passettype">
>
> <column name="etType__oid$_fk0" length="35"/>
> </many-to-one>
>
> </joined-subclass>
> </class>
> there is the following exception
> org.hibernate.HibernateException: instance not of expected entity type: com.finantix.fxc.persistents.directory.breakdown.lim.bl.pom.impl.PBreakdownItem
> at org.hibernate.persister.entity.BasicEntityPersister.getSubclassEntityPersister(BasicEntityPersister.java:2986)
> at org.hibernate.impl.SessionImpl.getEntityPersister(SessionImpl.java:1089)
> at org.hibernate.id.Assigned.generate(Assigned.java:31)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:85)
> at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:124)
> at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:84)
> at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
> at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:525)
> at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:529)
> at com.finantix.fxc.importfacilities.ImportFacilities.persistResource(ImportFacilities.java:195)
> at com.finantix.fxc.importfacilities.ImportFacilities.persistBasicComponent(ImportFacilities.java:164)
> at com.finantix.fxc.importfacilities.ImportFacilities.persistBasicPackage(ImportFacilities.java:121)
> at com.finantix.fxc.importfacilities.ImportFacilities.persistBasicDomain(ImportFacilities.java:104)
> at com.finantix.fxc.importfacilities.ImportFacilities.persistFromXML(ImportFacilities.java:75)
> at com.finantix.fxc.importfacilities.ImportFacilities.main(ImportFacilities.java:20)
--
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, 1 month
[Hibernate-JIRA] Closed: (HHH-1197) Support for HQL delete on MaxDB
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1197?page=c... ]
Steve Ebersole closed HHH-1197.
-------------------------------
Closing stale resolved issues
> Support for HQL delete on MaxDB
> -------------------------------
>
> Key: HHH-1197
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1197
> Project: Hibernate Core
> Issue Type: Improvement
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5, MaxDB 7.6, JBoss 4.0.1
> Reporter: Randahl Fink Isaksen
> Assignee: Gavin King
> Priority: Minor
> Fix For: 3.1
>
>
> When deleting an instance which has joined subclasses hibernate throws an exception if running on top of MaxDB claiming that the database dialect used does not support temporary tables.
> MaxDB does in fact support temporary tables - hibernate just does not know this - so I am requesting that Hibernate and/or the database dialect is improved so that these deletes are made possible. At the following address you will find a description of the SQL needed to create temporary tables with MaxDB
> http://dev.mysql.com/doc/maxdb/en/6d/117c14d14811d2a97400a0c9449261/conte...
> I am using MaxDB 7.6 and the SapDB dialect. (Might I also suggest that you rename the SapDB dialect to MaxDB since the database has been renamed?)
> I have taken the liberty of filing this as a critical bug as it means I cannot carry out certain deletions which are needed in my system.
> Below you will find the stack trace I encounter.
> Thank you for looking into this issue.
> Randahl
> Here is the stack trace thrown if you try deleting using MaxDB today:
> org.hibernate.HibernateException: cannot perform multi-table deletes using dialect not supporting temp tables
> at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.<init>(MultiTable
> DeleteExecutor.java:40)
> at org.hibernate.hql.ast.QueryTranslatorImpl.buildAppropriateStatementEx
> ecutor(QueryTranslatorImpl.java:423)
> at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorIm
> pl.java:172)
> at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl
> .java:103)
> at org.hibernate.impl.SessionFactoryImpl.getQuery(SessionFactoryImpl.jav
> a:473)
> at org.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:1060)
> at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:1041)
> at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:89)
--
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, 1 month
[Hibernate-JIRA] Closed: (HHH-1445) SchemaUpdate closes shared ConnectionProvider
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1445?page=c... ]
Steve Ebersole closed HHH-1445.
-------------------------------
Closing stale resolved issues
> SchemaUpdate closes shared ConnectionProvider
> ---------------------------------------------
>
> Key: HHH-1445
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1445
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.2
> Reporter: fdo
> Assignee: Steve Ebersole
> Fix For: 3.2.0.alpha1, 3.1.3
>
>
> Summary of thread : http://forum.hibernate.org/viewtopic.php?p=2289756
> - I have a standalone application, configured to use c3p0 as connection pool
> - when I first connect to the db, Hibernate updates the database using SchemaUpdate from SessionFactoryImpl. This schema update is created using the SchemaUpdate(cfg, settings) constructor [[this constructor didn't exist in Hibernate 3.0.5 but it does in 3.1.2]], which doesn't instantiate a new ConnectionProvider but uses the one from the settings
> - when SchemaUpdate is done, it closes the ConnectionProvider, which cannot be used afterwards
> - afterwards, when I try to do something on the database, it appears the (closed) connection provider from the settings is used and it explodes...
--
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, 1 month