[Hibernate-JIRA] Created: (HHH-2200) Memory leak in AbstractBatcher with Generated Properties
by Jay Paulsen (JIRA)
Memory leak in AbstractBatcher with Generated Properties
--------------------------------------------------------
Key: HHH-2200
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2200
Project: Hibernate3
Type: Bug
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0 GA; Oracle 10g; Java 1.5
Reporter: Jay Paulsen
Using Hibernate 3.2 GA with Entity Manager and Annotations, I have a batch job that inserts several thousands of objects for a class with a @Generated property. The job results in a memory leak in the AbstractBatcher class.
The problem appears to be in the method processGeneratedProperties in AbstractEntityPersister. This method closes the result set for the generated property query and calls session.getBatcher().closeStatement() to close the statement instead of session.getBatcher().closeQueryStatement to close both the statement and the result set. The result is that even though the result set is closed, it is not removed AbstractBatcher's resultSetsToClose HashSet.
Even though the batch job commits and clears the session every 200 rows, over time the leaked result sets in resultSetsToClose results in an OutOfMemory problem.
I've changed the code in AbstractEntityPersister.processGeneratedProperties to call session.getBatcher().closeQueryStatement and the same job then runs to completion without the memory leakage.
I noticed that this method in AbstractEntityPersister has had a recent change to fix a similar problem for issue HHH-1750, so I wanted to verify that this fix is the right approach.
--
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
16 years, 7 months
[Hibernate-JIRA] Created: (HHH-2078) for update on multiple tables does not work or is not present. cascade='lock' does not always work as specified.
by Peter Mutsaers (JIRA)
for update on multiple tables does not work or is not present. cascade='lock' does not always work as specified.
----------------------------------------------------------------------------------------------------------------
Key: HHH-2078
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2078
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: Oracle 9
Reporter: Peter Mutsaers
A normal one to many relationship between two classes, say A and B exists.
We have a cascade='lock' from A to B and also specified fetch='join'.
When I get only an instance of A, hibernate generates a left join between A and B.
When I get the instance while getting a lock, session.get(A.class, id, LockMode.UPGRADE),
I would expect and need an SQL statement along the lines of "select .. from A a left join B b on a.id=b.a_id FOR UPDATE", which would lock both A and its associated B instances.
Instead, hibernate even refuses to execute the join in this case, and fetches A and B with separate queries.
Also whatever I do, I cannot convince hibernate to generate a "for update" query without specifiying a specific table.
For example when A and B have fetch="select" and B is lazily loaded, and I have already retrieved an instance of A, then execute
session.lock(a, id, LockMode.UPGRADE), I would expect that the cascade='lock' would also lock B by either generating the left join over A and B, or by executing both "select ... from A for update" and "select ... from B for update".
Instead, only the first select statement is executed and B is NOT LOCKED at all in spite of the cascade='lock' instruction.
--
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
16 years, 7 months
[Hibernate-JIRA] Created: (HHH-2197) make more information about the persistent class available to NamingStrategy methods
by Jason Trump (JIRA)
make more information about the persistent class available to NamingStrategy methods
------------------------------------------------------------------------------------
Key: HHH-2197
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2197
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.2.0.ga
Environment: all environments
Reporter: Jason Trump
Priority: Minor
Currently NamingStrategy.propertyToColumnName() implementations are only passed the bare property name for persistent entities, without any information about which class is being persisted. It would be nice if the persistent classname was also provided, so that information about the class could be used in deciding how to generate the column name.
To give an example, in a client's database, all of the column names begin with an abbreviation of the table name itself:
create table TBL_Foo (
FooUuid tinyint primary key,
FooProperty varchar(32)
)
maps to class:
public class Foo {
private Integer uuid;
private String property;
....
}
Right now propertyToColumnName(String) is only called with the arguments "uuid" or "property", making it impossible to automatically prefix "Foo" with a NamingStrategy. To preserve backwards-compatibility, maybe we could get another version of propertyToColumnName, like
/**
* @param className fully-qualified className of the persistent class, or entity-name for non-pojo persistence
* @param propertyPath property name relative to <code>className</code>
*/
public String propertyToColumnName(String className, String propertyPath);
with similar overloaded versions on other methods in the interface, with the same idea. apologies if this type of thing is already available in the current release, but I didn't find evidence of this either in the forums or by inspecting the code.
thanks for hibernate and Hibernate entitymanager! i've been a fan for several years now.
--
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
16 years, 7 months
[Hibernate-JIRA] Created: (HHH-2098) Problem deleting entities in hierarchy
by Philippe Larouche (JIRA)
Problem deleting entities in hierarchy
--------------------------------------
Key: HHH-2098
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2098
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.2.0.cr3
Environment: Hibernate 3.2.0CR3 and Hibernate 3.2.0CR4, on an Oracle DB
Reporter: Philippe Larouche
Priority: Blocker
Hi, I'm using Hibernate 3.2.0 CR3 (also tried it with 3.2.0CR4) and when I try to delete entities in batch (with an HQL query), I got an error in the SQL translation of my query. I try to delete an entity that is the child of another one. Here are my mapping files:
Scancode (parent entity)......
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="com.cardinal.dal.entity.foundation.ScanCode" table="SCAN_CD_VW" schema="CDM_FND_1_0">
<composite-id name="id" class="com.cardinal.dal.entity.generated.foundation.ScanCodeId">
<key-property name="scanCdGuid" type="binary">
<meta attribute="use-in-equals" inherit="false">true</meta>
<column name="SCAN_CD_GUID"/>
</key-property>
<key-property name="operatingCntxGuid" type="binary">
<meta attribute="use-in-equals" inherit="false">true</meta>
<column name="OPERATING_CNTX_GUID"/>
</key-property>
</composite-id>
<version name="versionNum" column="VERSION_NUM" generated="always" unsaved-value="negative" insert="false"/>
<property name="dataDomainGuid" type="binary">
<column name="DATA_DOMAIN_GUID" not-null="true"/>
</property>
<property name="scanCdCls" type="string">
<column name="SCAN_CD_CLS" length="1" not-null="true"/>
</property>
<property name="scanCdTxt" type="string">
<column name="SCAN_CD_TXT" not-null="true"/>
</property>
<filter name="operatingCntxFilter" condition=":operatingCntxGuid = OPERATING_CNTX_GUID"/>
</class>
</hibernate-mapping>
PatientScancode (child entity).............
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<joined-subclass name="com.cardinal.dal.entity.patient.PatientScanCode" extends="com.cardinal.dal.entity.foundation.ScanCode" table="PATIENT_SCAN_CD_VW" schema="CDM_PAT_1_0">
<key>
<column name="PATIENT_SCAN_CD_GUID"/>
<column name="OPERATING_CNTX_GUID"/>
</key>
<property name="patientGuid" type="binary">
<meta attribute="scope-get" inherit="false">protected</meta>
<meta attribute="scope-set" inherit="false">protected</meta>
<column name="PATIENT_GUID"/>
</property>
<many-to-one name="patientVw" class="com.cardinal.dal.entity.patient.Patient" update="false" insert="false" fetch="select">
<column name="PATIENT_GUID" not-null="true"/>
<column name="OPERATING_CNTX_GUID"/>
</many-to-one>
</joined-subclass>
</hibernate-mapping>
Here's how I execute my delete statement in my session bean:
String queryStr = "delete from PatientScanCode as scancode " +
"where scancode.patientVw.id.partyGuid = ? ";
Query query = session.createQuery(queryStr);
query.setParameter(0, patientId.getPartyGuid());
query.executeUpdate();
I know that the query syntax is correct, the problem comes from the SQL translation made by Hibernate, here's what it looks like:
delete
from
CDM_PAT_1_0.PATIENT_SCAN_CD_VW
where
(
PATIENT_SCAN_CD_GUID, OPERATING_CNTX_GUID
) IN (
select
PATIENT_SCAN_CD_GUID,
OPERATING_CNTX_GUID
from
HT_PATIENT_SCAN_CD_VW
)
delete
from
CDM_FND_1_0.SCAN_CD_VW
where
(
SCAN_CD_GUID, OPERATING_CNTX_GUID
) IN (
select
PATIENT_SCAN_CD_GUID,
OPERATING_CNTX_GUID
from
HT_PATIENT_SCAN_CD_VW
)
There are 2 delete statements since it has to delete both the child and the parent. In the from clause in the select statement, the table called HT_PATIENT_SCAN_CD_VW is used, but it doesn't exist in our model. I suppose it should be a temporary table created by hibernate to keep in memory which rows have to be deleted when it's time to delete the parent table. The problem is that this table doesn't seem to be created properly before running delete statements cause I get the following exception when it is called on the database:
19:04:06,001 ERROR [JDBCExceptionReporter] ORA-00918: column ambiguously defined
19:04:06,017 WARN [MultiTableDeleteExecutor] unable to cleanup temporary id table after use
java.sql.SQLException: ORA-00942: table or view does not exist
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3368)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.hibernate.hql.ast.exec.AbstractStatementExecutor.dropTemporaryTableIfNecessary(AbstractStatementExecutor.java:179)
at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.execute(MultiTableDeleteExecutor.java:136)
at org.hibernate.hql.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:391)
at org.hibernate.engine.query.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:259)
at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:1134)
at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:94)
at com.cardinal.dal.session.patient.PatientScanCodeBean.deleteAllByPatient(PatientScanCodeBean.java:75)
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.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
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.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
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.localInvoke(StatelessContainer.java:181)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
at $Proxy866.deleteAllByPatient(Unknown Source)
at testng.com.cardinal.dal.session.patient.PatientScanCodeTestBean.deleteAllByPatient(PatientScanCodeTestBean.java:101)
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.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
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.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
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:225)
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:828)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
19:04:06,095 ERROR [PatientScanCodeBean] Error in com.cardinal.dal.session.patient.PatientScanCodeBean.invoke0(): org.hibernate.exception.SQLGrammarException: could not insert/select ids for bulk delete
org.hibernate.exception.SQLGrammarException: could not insert/select ids for bulk delete
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.execute(MultiTableDeleteExecutor.java:102)
at org.hibernate.hql.ast.QueryTranslatorImpl.executeUpdate(QueryTranslatorImpl.java:391)
at org.hibernate.engine.query.HQLQueryPlan.performExecuteUpdate(HQLQueryPlan.java:259)
at org.hibernate.impl.SessionImpl.executeUpdate(SessionImpl.java:1134)
at org.hibernate.impl.QueryImpl.executeUpdate(QueryImpl.java:94)
at com.cardinal.dal.session.patient.PatientScanCodeBean.deleteAllByPatient(PatientScanCodeBean.java:75)
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.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
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.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
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.localInvoke(StatelessContainer.java:181)
at org.jboss.ejb3.stateless.StatelessLocalProxy.invoke(StatelessLocalProxy.java:79)
at $Proxy866.deleteAllByPatient(Unknown Source)
at testng.com.cardinal.dal.session.patient.PatientScanCodeTestBean.deleteAllByPatient(PatientScanCodeTestBean.java:101)
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.ejb3.tx.BMTInterceptor.handleStateless(BMTInterceptor.java:71)
at org.jboss.ejb3.tx.BMTInterceptor.invoke(BMTInterceptor.java:131)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.TxPropagationInterceptor.invoke(TxPropagationInterceptor.java:76)
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.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:78)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:47)
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:225)
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:828)
at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:681)
at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:358)
at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:412)
at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:239)
Caused by: java.sql.SQLException: ORA-00918: column ambiguously defined
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:743)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216)
at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:955)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:3368)
at org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:251)
at org.hibernate.hql.ast.exec.MultiTableDeleteExecutor.execute(MultiTableDeleteExecutor.java:93)
... 67 more
Thx to keep me posted on this one
Phil
--
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
16 years, 7 months
[Hibernate-JIRA] Created: (HHH-2149) Wrong SQL generated with delete HQL
by jeremie balcaen (JIRA)
Wrong SQL generated with delete HQL
-----------------------------------
Key: HHH-2149
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2149
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.1.3
Environment: Hibernate version 3.1.3
oracle version 9
Reporter: jeremie balcaen
Priority: Minor
Here is the delete HQL statement :
delete Label label where label.numseq = '01' and label.codlan = '01'" and label.mytad.argtbl = 'BE' and label.mytad.numbtl = '054'
The generated SQL is :
delete from JPRG.LABEL, MYTAD mytad1_ where NUMSEQ='01' and CODLAN='01' and ARGTBL='BE' and NUMBTL='054'
Here are the mapping files :
<hibernate-mapping package="com.cwsoft.businessobject">
<class name="Label" table="LABEL" >
<composite-id>
<key-many-to-one name="mytad">
<column name="NUMBTL"/>
<column name="ARGTBL"/>
</key-many-to-one>
<key-property name="numseq" type="string">
<column name="NUMSEQ"/>
</key-property>
<key-property name="codlan" type="string">
<column name="CODLAN"/>
</key-property>
</composite-id>
<property name="labele" column="LABELE" type="string" not-null="true" />
</class>
</hibernate-mapping>
The associated class is defined with a composite-id : (with id, it works fine)
<hibernate-mapping package="com.cwsoft.businessobject">
<class name="Mytad" table="MYTAD">
<composite-id>
<key-property name="numbtl" type="string">
<column name="NUMBTL"/>
</key-property>
<key-property name="argtbl" type="string">
<column name="ARGTBL"/>
</key-property>
</composite-id>
<property name="thdesc" type="string" column="THDESC"/>
</class>
</hibernate-mapping>
--
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
16 years, 7 months
[Hibernate-JIRA] Created: (HHH-2113) Incorrect join ordering with filters and JOINED inheritance
by Barney Boisvert (JIRA)
Incorrect join ordering with filters and JOINED inheritance
-----------------------------------------------------------
Key: HHH-2113
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2113
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr4
Environment: Hibernate 3.2.0 CR4, MySQL 4.1.20
Reporter: Barney Boisvert
I've a TextBlock object that extends AbstractContentObject (and has myriad other associations illustrated here, but irrelevant) and when doing a polymorphic query for all AbstractContentObjects Hibernate runs this SQL (note the line with the trailing asterisks):
select
textblockv0_.id as id21_5_,
textblockv0_.createTimestamp as createTi2_21_5_,
textblockv0_.hibernateVersionId as hibernat3_21_5_,
textblockv0_.lastUpdateTimestamp as lastUpda4_21_5_,
textblockv0_.lastVersionNumber as lastVers5_21_5_,
textblockv0_.activeVersionId as activeVe6_21_5_,
textblockv1_.id as id20_0_,
textblockv1_.createTimestamp as createTi2_20_0_,
textblockv1_.hibernateVersionId as hibernat3_20_0_,
textblockv1_.lastUpdateTimestamp as lastUpda4_20_0_,
textblockv1_.versionNumber as versionN5_20_0_,
textblockv1_.frozen as frozen20_0_,
textblockv1_.commitMessage as commitMe7_20_0_,
textblockv1_.title as title20_0_,
textblockv1_.summary as summary20_0_,
textblockv1_.text as text20_0_,
textblockv1_.versionHistoryId as version11_20_0_,
textblockv2_.id as id21_1_,
textblockv2_.createTimestamp as createTi2_21_1_,
textblockv2_.hibernateVersionId as hibernat3_21_1_,
textblockv2_.lastUpdateTimestamp as lastUpda4_21_1_,
textblockv2_.lastVersionNumber as lastVers5_21_1_,
textblockv2_.activeVersionId as activeVe6_21_1_,
textblock3_.id as id18_2_,
textblock3_1_.createTimestamp as createTi2_18_2_,
textblock3_1_.hibernateVersionId as hibernat3_18_2_,
textblock3_1_.siteId as siteId18_2_,
textblock3_1_.orderCol as orderCol18_2_,
textblock3_1_.folderId as folderId18_2_,
textblock3_.versionHistoryId as versionH2_19_2_,
site4_.id as id1_3_,
site4_.createTimestamp as createTi2_1_3_,
site4_.hibernateVersionId as hibernat3_1_3_,
site4_.lastUpdateTimestamp as lastUpda4_1_3_,
site4_.name as name1_3_,
site4_.parentId as parentId1_3_,
site4_.timeZone as timeZone1_3_,
site4_.familyId as familyId1_3_,
site4_.externalSiteAccessControl as external7_1_3_,
site4_.canonicalDomainId as canonic10_1_3_,
folder5_.id as id17_4_,
folder5_.createTimestamp as createTi2_17_4_,
folder5_.hibernateVersionId as hibernat3_17_4_,
folder5_.lastUpdateTimestamp as lastUpda4_17_4_,
folder5_.leftCol as leftCol17_4_,
folder5_.rightCol as rightCol17_4_,
folder5_.siteId as siteId17_4_,
folder5_.title as title17_4_
from
TextBlockVersionHistory textblockv0_
left outer join
TextBlockVersion textblockv1_
on textblockv0_.activeVersionId=textblockv1_.id
left outer join
TextBlockVersionHistory textblockv2_
on textblockv1_.versionHistoryId=textblockv2_.id
left outer join
TextBlock textblock3_
on textblockv0_.id=textblock3_.versionHistoryId
and ? = textblock3_1_.siteId -- **************************************************
left outer join
AbstractContentObject textblock3_1_
on textblock3_.id=textblock3_1_.id
left outer join
Site site4_
on textblock3_1_.siteId=site4_.id
left outer join
Folder folder5_
on textblock3_1_.folderId=folder5_.id
where
textblockv0_.id=?
The highlighted condition is applied via a filter on AbstractContentObject:
@javax.persistence.Entity
@Inheritance(strategy = InheritanceType.JOINED)
@Filter(name = "siteVisibility", condition = ":siteId = siteId")
@Table(uniqueConstraints = @UniqueConstraint( columnNames = { "folderId", "order"}))
public abstract class AbstractContentObject
However, the actual SQL condition is supplied to the wrong LEFT OUTER JOIN. It should be supplied against the AbstractContentObject JOIN that immediately follows the condition. I.e. move the condition down three lines, and it should work.
--
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
16 years, 7 months
[Hibernate-JIRA] Created: (HHH-2018) Cannot map views in postgres unless hbm2ddl.auto is unset
by Dave E Martin (JIRA)
Cannot map views in postgres unless hbm2ddl.auto is unset
---------------------------------------------------------
Key: HHH-2018
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2018
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr2
Environment: hibernate 3.2cr2 annotations 3.2cr1 postgresql 8.1 with postgresql-8.1-404.jdbc3.jar
This is also a problem in hibernate 3.1
Reporter: Dave E Martin
Attempting to map a view with hibernate results in:
Exception in thread "main" org.hibernate.HibernateException: Missing table: monthly_block_totals_utc
Even though this exists (as a view) in the database.
making sure hbm2ddl.auto is not set allows the application to work, but at the expense of being unable to update or validate the schema (or allow the end user to control whether the schema should be updated or not).
Furthermore, there doesn't appear to be a 'none' or any documented way to set .auto to something which would be the equivalent of it not being set. (or to clear it out of the properties, and setting it to null doesn't work either).
This appears to be related to HHH-1329 and HHH-1473.
Stepping into the process reveals that postgres apparently reports views as views and not tables, causing them to be overlooked by Hibernate when its validating.
--
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
16 years, 8 months