[Hibernate-JIRA] Updated: (HHH-957) SubqueryExpression throws ClassCastException on DetachedCriteria subqueries
by Thomas Goorden (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-957?page=all ]
Thomas Goorden updated HHH-957:
-------------------------------
Attachment: subcriteria-patch.txt
This is slightly more elegant patch, that adds a getSession() method to the Criteria interface and implements it in Subcriteria.
> SubqueryExpression throws ClassCastException on DetachedCriteria subqueries
> ---------------------------------------------------------------------------
>
> Key: HHH-957
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-957
> Project: Hibernate3
> Type: Bug
> Versions: 3.0.5
> Environment: Oracle 9i, but probably not DB specific.
> Reporter: Rob MacGrogan
> Priority: Minor
> Attachments: SubqueryExpression.java, SubqueryExpression.java, subcriteria-patch.txt
>
>
> The toSqlString() method in SubqueryExpression contains a line that casts a Criteria object to CriteriaImpl in order to call the getSession() method. However, if DetachedCriteria is used as a subquery in a Criteria query, the underlying Criteria object will be CriteriaImpl.Subcriteria, thus a ClassCastException will be thrown.
> I have created a bug fix. Add the following method to SubqueryExpression:
> private SessionImpl getSessionImpl(Criteria criteria) {
> SessionImpl session = null;
> if (criteria instanceof CriteriaImpl) {
> CriteriaImpl impl = (CriteriaImpl)criteria;
> session = impl.getSession();
> }
> else if (criteria instanceof CriteriaImpl.Subcriteria){
> CriteriaImpl.Subcriteria sub = (CriteriaImpl.Subcriteria)criteria;
> //Alert! Recursive call here!
> session = getSessionImpl(sub.getParent());
> }
> return session;
> }
> And then replace the offending line in toSqlString() with a call to the new method.
> Attached is SubqueryExpression with proposed changes in 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
19 years
[Hibernate-JIRA] Created: (HHH-2271) HbmBinder.getResultCheckStyle ignore callables sql-XXX (sql-update, sql-delete, etc)
by German de la Cruz (JIRA)
HbmBinder.getResultCheckStyle ignore callables sql-XXX (sql-update, sql-delete, etc)
------------------------------------------------------------------------------------
Key: HHH-2271
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2271
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Reporter: German de la Cruz
Priority: Blocker
the method hbmBinder.getResultCheckStyle doent' take into account the callable parameter
As a result, in a sql-update like this
<sql-update callable="true" >{? = call trader.updateXX(?,?,?,?,?,?,?,?,?,?,?,?)}</sql-update>
Hibernate doen't register the outbound parameter, because in AbstratEntityPersister. update (the one that returns a boolean) it gets a BasicExpectation intead of a BasicParamExpectation, the one who does it.
I think the solution is something like that
private static ExecuteUpdateResultCheckStyle getResultCheckStyle(Element element, boolean callable) throws MappingException {
Attribute attr = element.attribute( "check" );
if ( attr == null ) {
if(callable){
return ExecuteUpdateResultCheckStyle.PARAM;
}
// use COUNT as the default. This mimics the old behavior, although
// NONE might be a better option moving forward in the case of callable
return ExecuteUpdateResultCheckStyle.COUNT;
}
return ExecuteUpdateResultCheckStyle.parse( attr.getValue() );
}
Thanks
--
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
19 years
[Hibernate-JIRA] Created: (ANN-491) Collection mapped with javax.persistence.MapKey isn't loaded properly.
by Magnus Heino (JIRA)
Collection mapped with javax.persistence.MapKey isn't loaded properly.
----------------------------------------------------------------------
Key: ANN-491
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-491
Project: Hibernate Annotations
Type: Bug
Versions: 3.2.0.ga
Reporter: Magnus Heino
http://forum.hibernate.org/viewtopic.php?t=966948
Add this test to IndexedCollectionTest.java:
public void testMapKeyLoad() throws Exception {
Session s;
Transaction tx;
s = openSession();
tx = s.beginTransaction();
Software hibernate = new Software();
hibernate.setName( "Hibernate" );
Version v1 = new Version();
v1.setCodeName( "HumbaHumba" );
v1.setNumber( "1.0" );
v1.setSoftware( hibernate );
hibernate.addVersion(v1);
s.persist(hibernate);
s.persist(v1);
tx.commit();
s.clear();
tx = s.beginTransaction();
hibernate = (Software) s.get( Software.class, "Hibernate" );
Version v2 = new Version();
v2.setCodeName( "HumbaHumba" );
v2.setNumber( "2.0" );
v2.setSoftware( hibernate );
hibernate.addVersion(v2);
assertEquals("One loaded persisted version, and one just added", 2, hibernate.getVersions().size() );
tx.commit();
s.clear();
tx = s.beginTransaction();
hibernate = (Software) s.get( Software.class, "Hibernate" );
for ( Version v : hibernate.getVersions().values() ) {
s.delete( v );
}
s.delete( hibernate );
tx.commit();
s.close();
}
And modify Software.java to look like this:
//$Id: Software.java 9795 2006-04-26 06:41:18Z epbernard $
package org.hibernate.test.annotations.indexcoll;
import java.util.HashMap;
import java.util.Map;
import javax.persistence.Entity;
import javax.persistence.Id;
import javax.persistence.MapKey;
import javax.persistence.OneToMany;
/**
* @author Emmanuel Bernard
*/
@Entity
public class Software {
private String name;
private Map<String, Version> versions;
public Software() {
this.versions = new HashMap<String, Version>();
}
@Id
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
@OneToMany(mappedBy = "software")
@MapKey(name = "codeName")
public Map<String, Version> getVersions() {
return versions;
}
public void setVersions(Map<String, Version> versions) {
this.versions = versions;
}
public void addVersion(Version version) {
this.getVersions().put(version.getCodeName(), version);
}
}
AFAIK addVersion should be able to do this.version.put too if you read the spec, but it doesn't work with the getter as it is now either.
--
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
19 years
[Hibernate-JIRA] Created: (ANN-477) @Formula doesn't work in entities referenced by @JoinColumn(referencedColumnName="...")
by Salvatore Insalaco (JIRA)
@Formula doesn't work in entities referenced by @JoinColumn(referencedColumnName="...")
---------------------------------------------------------------------------------------
Key: ANN-477
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-477
Project: Hibernate Annotations
Type: Bug
Versions: 3.2.0.ga
Reporter: Salvatore Insalaco
Attachments: ProvaBug.zip
See the attached test (build with ant, place hibernate libraries in lib, run test.Test).
Entity Second has a @Formula property.
Entity First has a many-to-one association with Second, not on the primary key but on the ALT_ID column, using the "referencedColumnName" attribute of the @JoinColumn annotation.
This is NOT the case of an association to a @Formula column (not supported), but a relation on a non-primary column of an entity that happens to have a @Formula property.
During SessionFactory creation an exeption is raised:
java.lang.ClassCastException: org.hibernate.mapping.Formula
at org.hibernate.cfg.BinderHelper.findPropertiesByColumns(BinderHelper.java:234)
at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:106)
at org.hibernate.cfg.FkSecondPass.doSecondPass(FkSecondPass.java:63)
at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:428)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:286)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1210)
The bug lies in BinderHelper.findPropertiesByColumns. In the iteration starting at line 233, it tries to find the property that maps the "referencedColumnName", but it doesn't consider that some properties may not have a Column, only a Formula.
The correct version should be something like this:
Iterator columnIt = property.getColumnIterator();
while ( columnIt.hasNext() ) {
Object next = columnIt.next();
if (next instanceof Column) {
Column column = (Column)next;
if ( columnsToProperty.containsKey( column ) ) {
columnsToProperty.get( column ).add( property );
}
}
}
--
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
19 years
[Hibernate-JIRA] Commented: (HHH-1786) JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
by Heinz Huber (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786?page=c... ]
Heinz Huber commented on HHH-1786:
----------------------------------
Fix works like a charm. I made one adjustment: Direct use of Integer instead of String as key.
Since this is a known problem of WebSphere, I'd appriciate if hibernate would handle this until IBM fixes the problem.
> JTASessionContext.CleanupSynch does not remove sessions from currentSessionMap
> ------------------------------------------------------------------------------
>
> Key: HHH-1786
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1786
> Project: Hibernate3
> Type: Improvement
> Versions: 3.1.2
> Environment: IBM WebSphere 6.0.2.7, Hibernate CVS snapshot from 2006-02-24
> Reporter: Tomi Szabo
> Attachments: JTASessionContext.java
>
>
> We are using JTASessionContext, CMTTransaction and WebSphereExtendedJTATransactionLookup. We have experienced some memmory leak problems and after closer inspection we have found that Hibernate sessions are not removed from currentSessionMap inside JTASessionContext.
> Method JTASessionContext.CleanupSynch.afterCompletion() is called as expected but code "context.currentSessionMap.remove( txn );" does not remove session from Map because of key's hashcode has changed. This is due to fact that com.ibm.websphere.jtaextensions.ExtendedJTATransaction.hashCode is actually ID of underlaying transaction. But if it comes to the afterCompletion method in CleanupSynch the underlaying transaction is already closed. Closed transaction has ID 0 (default value) and it is different from ID under which the Hibernate session was previously inserted into Map.
> Possible patch is in attachements.
--
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
19 years
[Hibernate-JIRA] Updated: (HHH-1258) startup time improvements
by Mike Quilleash (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=all ]
Mike Quilleash updated HHH-1258:
--------------------------------
Attachment: LazyProxyFactory.patch
New patch with changes detailed above.
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: AbstractEntityTuplizer.patch, Environment.patch, LazyProxyFactory.patch, SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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
19 years
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Mike Quilleash (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Mike Quilleash commented on HHH-1258:
-------------------------------------
#1: I realise this a configuration level object rather than a run-time one so ideally it wouldn't be kept hanging around but I didn't see an easy way of doing this. You could null it out once the factory is created to have it reclaimed. Don't know about the event listener stuff, I'm new to H3.
#2: Just adding synchronized to the getProxy() method of the LazyProxyFactory would do it. It's certainly safer, not sure if it is necessary. I believe this will work with any byte code plugin because that is all hidden behind the buildProxyFactory() protected abstract. All this patch does is delay that initial call from construction time to first-proxy-request time. I haven't tested with javaassist specifically only cglib.
#3: In the old code the constructor of AbstractEntityTuplizer did the following:
if ( entityMetamodel.isLazy() ) {
proxyFactory = buildProxyFactory( mappingInfo, idGetter, idSetter );
if (proxyFactory == null) {
entityMetamodel.setLazy( false );
}
}
So if the proxy factory creation returned null it would set the entity model to non-lazy. I would've thought an exception would be better than silently setting the model to non-lazy but maybe I'm missing something.
The lazy wrapper does not expect a null return from buildProxyFactory() at the moment so this would have to checked and an exception thrown if a null return is possible. At this point I suspect it is not safe to set the entity model back to non-lazy.
I'll make the synchronization, null out of PersistentClass and check of null return from buildProxyFactory() and resubmit in a single patch file.
I'll run the result through the test suite, see if there's any major problems.
Feel free to delete the old attachments I made.
Cheers.
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: AbstractEntityTuplizer.patch, Environment.patch, SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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
19 years
[Hibernate-JIRA] Created: (HHH-2270) Could not synchronize database state with session - and contraint problem
by Koka Durgababu (JIRA)
Could not synchronize database state with session - and contraint problem
-------------------------------------------------------------------------
Key: HHH-2270
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2270
Project: Hibernate3
Type: Bug
Versions: 3.1.3
Environment: Hibernate 3.1.3,Oracle 9, WSAD
Reporter: Koka Durgababu
Hi
Here is my code...
if(userSkippedItems != null)
{
tx = session.beginTransaction();
for(int i=0;i<userSkippedItems.length;i++)
{
System.out.println("selectedSkipItems.length Manager--------> " +userSkippedItems.length);
IBCSearchDAO ibcDAO = new IBCSearchDAO();
ibcDAO = ibcManager.loadTftImpBillTnx(session,userSkippedItems[i]);
if(ibcDAO != null)
{
// Insert into master table first
session.save(setImpDAO(ibcDAO));
session.flush(); //force the SQL INSERT
// Insert into Transaction table
session.save(setImpTnxDAO(ibcDAO,i));
session.flush(); //force the SQL INSERT
}
tx.commit();
}
}
----------------------and the log is
int (OPS$CBIR.CBIR_IMP_PK) violated
[11/29/06 16:33:37:765 SGT] 197d6476 AbstractFlush E org.hibernate.event.def.AbstractFlushingEventListener Could not synchronize database state with session
[11/29/06 16:33:37:827 SGT] 2c0ba470 AbstractFlush E org.hibernate.event.def.AbstractFlushingEventListener Could not synchronize database state with session
[11/29/06 16:33:37:843 SGT] 197d6476 AbstractFlush E org.hibernate.event.def.AbstractFlushingEventListener TRAS0014I: The following exception was logged org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
at com.bnp.cbir.manager.CBIRImpTnxManager.saveSkipItems(CBIRImpTnxManager.java:93)
at com.bnp.cbir.actions.SkipSubmitAction.execute(SkipSubmitAction.java:79)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.ServicingServletState.service(StrictLifecycleServlet.java:333)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:983)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (OPS$CBIR.CBIR_IMP_PK) violated
at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:431)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:3049)
at com.ibm.ws.rsadapter.jdbc.WSJdbcStatement.executeBatch(WSJdbcStatement.java:352)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
... 32 more
.
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
at com.bnp.cbir.manager.CBIRImpTnxManager.saveSkipItems(CBIRImpTnxManager.java:93)
at com.bnp.cbir.actions.SkipSubmitAction.execute(SkipSubmitAction.java:79)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.ServicingServletState.service(StrictLifecycleServlet.java:333)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:983)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (OPS$CBIR.CBIR_IMP_PK) violated
at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:431)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:3049)
at com.ibm.ws.rsadapter.jdbc.WSJdbcStatement.executeBatch(WSJdbcStatement.java:352)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
... 32 more
[11/29/06 16:33:37:843 SGT] 2c0ba470 AbstractFlush E org.hibernate.event.def.AbstractFlushingEventListener TRAS0014I: The following exception was logged org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
at com.bnp.cbir.manager.CBIRImpTnxManager.saveSkipItems(CBIRImpTnxManager.java:93)
at com.bnp.cbir.actions.SkipSubmitAction.execute(SkipSubmitAction.java:79)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:983)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (OPS$CBIR.CBIR_IMP_PK) violated
at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:431)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:3049)
at com.ibm.ws.rsadapter.jdbc.WSJdbcStatement.executeBatch(WSJdbcStatement.java:352)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
... 32 more
.
org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:71)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:249)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:235)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:139)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:297)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:993)
at com.bnp.cbir.manager.CBIRImpTnxManager.saveSkipItems(CBIRImpTnxManager.java:93)
at com.bnp.cbir.actions.SkipSubmitAction.execute(SkipSubmitAction.java:79)
at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:484)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:274)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:983)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
Caused by: java.sql.BatchUpdateException: ORA-00001: unique constraint (OPS$CBIR.CBIR_IMP_PK) violated
at oracle.jdbc.dbaccess.DBError.throwBatchUpdateException(DBError.java:431)
at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:3049)
at com.ibm.ws.rsadapter.jdbc.WSJdbcStatement.executeBatch(WSJdbcStatement.java:352)
at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:242)
... 32 more
[11/29/06 16:33:38:374 SGT] 197d6476 WebGroup E SRVE0026E: [Servlet Error]-[action]: java.lang.NullPointerException
at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:441)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.ServicingServletState.service(StrictLifecycleServlet.java:333)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:983)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
[11/29/06 16:33:38:405 SGT] 2c0ba470 WebGroup E SRVE0026E: [Servlet Error]-[action]: java.lang.NullPointerException
at org.apache.struts.action.RequestProcessor.processForwardConfig(RequestProcessor.java:441)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:279)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1482)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:525)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:983)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:564)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:200)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:119)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:276)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:182)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:618)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:443)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:672)
--
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
19 years
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Max Rydahl Andersen commented on HHH-1258:
------------------------------------------
Hi Mike,
Thanks for the (upcoming) patches - if you could add them as one in a zip or one big patch then it becomes much easier to maintain.
Regarding your downsides:
#1: keeping PersistentClass is not optimal, but I guess it is "ok" and the users can avoid any issues when reusing the configuration is to serialize/deserialize the configuration before using it again. (there are also issues with this if you e.g. register specifc event listener instances)
#2: yes, a synchronization is probably needed here and in javaassist (does your patch work with javassist too or ?)
#3: i don't follow this one...?
again, i'm very interested in this issue and we are getting closer to something that could be an *option* to support but needs some more digging/verification to put it in core.
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: AbstractEntityTuplizer.patch, Environment.patch, SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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
19 years