[Hibernate-JIRA] Created: (HHH-7020) Connection leak with nested sessions
by Zoltán Holub (JIRA)
Connection leak with nested sessions
------------------------------------
Key: HHH-7020
URL: https://hibernate.onjira.com/browse/HHH-7020
Project: Hibernate ORM
Issue Type: Bug
Components: core, entity-manager
Affects Versions: 4.0.1, 4.0.0.Final, 4.1.0
Environment: Windows 7.
Java 1.6.0_25, Java 1.7.0
Reporter: Zoltán Holub
Attachments: testcase-connectionleak.zip
I'am using a Hibernate interceptor to track data modifications. In the interceptor's onFlushDirty() method, i open a new session without interceptors using the same JDBC connection.
After closing this nested session and the original entitymanager, the JDBC connection doesn't released.
I could reproduce this problem outside any interceptor. I have made a junit test without interceptors which shows the same problem.
I have found that Hibernate throws and catches a HibernateException with message "proxy handle is no longer valid". This exception is logged on debug level.
I investigated that the problem is in the following code:
LogicalConnectionImpl.java
public Connection close() {
LOG.trace( "Closing logical connection" );
Connection c = isUserSuppliedConnection ? physicalConnection : null;
try {
releaseProxies();
jdbcResourceRegistry.close();
if ( !isUserSuppliedConnection && physicalConnection != null ) {
releaseConnection();
}
return c;
}
finally {
// no matter what
physicalConnection = null;
isClosed = true;
LOG.trace( "Logical connection closed" );
for ( ConnectionObserver observer : observers ) {
observer.logicalConnectionClosed();
}
observers.clear();
}
}
The invocation of jdbcResourceRegistry.close() throws this exception, and this is why it skips the following releaseConnection(). The condition of IF statement is true.
This code is new to Hibernate 4. I have tried 4.0.0, 4.0.1 and 4.1.0-SNAPSHOT and all of them has the problem. Hibernate 3.6.0 is not affected.
My JUnit test could run with Hibernate 3.x with minor changes. (3.x code also in the JUnit test)
I have tried different ways to work around the problem. The only way it worked is to use a simple doWork() and native JDBC operations. This test case also in the unit test.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HHH-7084) Caused by: java.lang.ClassCastException: cannot be cast to org.hibernate.dialect.Dialect
by Artem V. Navrotskiy (JIRA)
Caused by: java.lang.ClassCastException: cannot be cast to org.hibernate.dialect.Dialect
----------------------------------------------------------------------------------------
Key: HHH-7084
URL: https://hibernate.onjira.com/browse/HHH-7084
Project: Hibernate ORM
Issue Type: Bug
Components: core
Affects Versions: 4.1.0
Environment: Idea 11.0.02, JDK 7, GWT 2.4.0 Dev Mode, Hibernate 4.0.0+
Reporter: Artem V. Navrotskiy
Attachments: classloader.patch
If you run GWT application from JetBrains Idea in Dev Mode, GWT builds custom ClassLoader.
When Hibernate creates of any object by it's name (Dialect for example), if class available for SystemClassLoader it's will be created by SystemClassLoader. Not by a current ClassLoader.
This is due to the fact that the class ClassLoaderServiceImpl$1 uses SystemClassLoader as parent ClassLoader.
Stacktrace:
javax.persistence.PersistenceException: Unable to build EntityManagerFactory
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:914)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:889)
at ru.buzzsoft.common.HibernateHelper.createEntityManagerFactory(HibernateHelper.java:180)
at ru.buzzsoft.delivery.PersistentFactory.getEntityPersonalFactory(PersistentFactory.java:21)
at ru.buzzsoft.delivery.server.api.impl.ContextImpl.<init>(ContextImpl.java:126)
at ru.buzzsoft.delivery.server.api.impl.ContextImpl.<init>(ContextImpl.java:89)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at java.lang.Class.newInstance0(Class.java:372)
at java.lang.Class.newInstance(Class.java:325)
at org.mortbay.jetty.servlet.Holder.newInstance(Holder.java:153)
at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:253)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:616)
at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
at org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1220)
at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:513)
at org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448)
at com.google.gwt.dev.shell.jetty.JettyLauncher$WebAppContextWithReload.doStart(JettyLauncher.java:468)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.handler.RequestLogHandler.doStart(RequestLogHandler.java:115)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
at org.mortbay.jetty.Server.doStart(Server.java:222)
at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:39)
at com.google.gwt.dev.shell.jetty.JettyLauncher.start(JettyLauncher.java:672)
at com.google.gwt.dev.DevMode.doStartUpServer(DevMode.java:509)
at com.google.gwt.dev.DevModeBase.startUp(DevModeBase.java:1068)
at com.google.gwt.dev.DevModeBase.run(DevModeBase.java:811)
at com.google.gwt.dev.DevMode.main(DevMode.java:311)
Caused by: org.hibernate.HibernateException: Could not instantiate dialect class
at org.hibernate.service.jdbc.dialect.internal.DialectFactoryImpl.constructDialect(DialectFactoryImpl.java:82)
at org.hibernate.service.jdbc.dialect.internal.DialectFactoryImpl.buildDialect(DialectFactoryImpl.java:64)
at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:146)
at org.hibernate.service.internal.StandardServiceRegistryImpl.configureService(StandardServiceRegistryImpl.java:75)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.initializeService(AbstractServiceRegistryImpl.java:159)
at org.hibernate.service.internal.AbstractServiceRegistryImpl.getService(AbstractServiceRegistryImpl.java:131)
at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:71)
at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2273)
at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2269)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1738)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:88)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:904)
... 32 more
Caused by: java.lang.ClassCastException: org.hibernate.dialect.H2Dialect cannot be cast to org.hibernate.dialect.Dialect
at org.hibernate.service.jdbc.dialect.internal.DialectFactoryImpl.constructDialect(DialectFactoryImpl.java:73)
... 43 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HHH-7189) AliasToBeanResultTransformer: query accesses fields of another class.
by Orlando Becerra (JIRA)
AliasToBeanResultTransformer: query accesses fields of another class.
---------------------------------------------------------------------
Key: HHH-7189
URL: https://hibernate.onjira.com/browse/HHH-7189
Project: Hibernate ORM
Issue Type: New Feature
Components: query-hql
Environment: All
Reporter: Orlando Becerra
Priority: Critical
The problem arises when you want to transform the query result to an object when the query accesses fields of another class.
Sample:
List<Employee> list =
s.createQuery(""
+ "SELECT E.name as name, E.deparment.name as deparment_name "
+ "FROM "
+ Employee.class.getName()).
setResultTransformer(new AliasToBeanResultTransformer(Employee.class)).
list();
Where the departmet is a field of Employee class and we only want retrieve the department's name.
att:
Oracle Certified Master Java Developers: Orlando Becerra, Luis Gonzalez and Nelson Moncada.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HHH-7188) Binder fails to pop context off of stack after processing each entity source
by John Verhaeg (JIRA)
Binder fails to pop context off of stack after processing each entity source
----------------------------------------------------------------------------
Key: HHH-7188
URL: https://hibernate.onjira.com/browse/HHH-7188
Project: Hibernate ORM
Issue Type: Bug
Components: metamodel
Affects Versions: 5.0.0
Reporter: John Verhaeg
Assignee: John Verhaeg
Fix For: 5.0.0
Popping the context off the stack in the finally block that was intended for this purpose, however, will not work since the attributes (and things for the root entity) are bound afterwards, but still need access to the context. Due to the root entity being handled differently than other entities, pushing the context onto the stack for it needs to also be handled differently than other entities.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HHH-7186) Enabling 2nde level cache with filtered collections.
by Lucas POUZAC (JIRA)
Enabling 2nde level cache with filtered collections.
----------------------------------------------------
Key: HHH-7186
URL: https://hibernate.onjira.com/browse/HHH-7186
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 4.1.1, 4.0.1, 3.3.1
Reporter: Lucas POUZAC
Actually, when we use filtered collection, the 2nde level cache can't be activate.
Below, the code snippet :
{code:title=org.hibernate.engine.loading.internal.CollectionLoadContext.java|borderStyle=solid}
/**
* Add the collection to the second-level cache
*
* @param lce The entry representing the collection to add
* @param persister The persister
*/
private void addCollectionToCache(LoadingCollectionEntry lce, CollectionPersister persister) {
...
if ( !session.getEnabledFilters().isEmpty() && persister.isAffectedByEnabledFilters( session ) ) {
// some filters affecting the collection are enabled on the session, so do not do the put into the cache.
LOG.debug( "Refusing to add to cache due to enabled filters" );
// todo : add the notion of enabled filters to the CacheKey to differentiate filtered collections from non-filtered;
// but CacheKey is currently used for both collections and entities; would ideally need to define two seperate ones;
// currently this works in conjuction with the check on
// DefaultInitializeCollectionEventHandler.initializeCollectionFromCache() (which makes sure to not read from
// cache with enabled filters).
return; // EARLY EXIT!!!!!
}
...
}
{code}
{code:title=org.hibernate.event.internal.DefaultInitializeCollectionEventListener.java|borderStyle=solid}
/**
* Try to initialize a collection from the cache
*
* @param id The id of the collection of initialize
* @param persister The collection persister
* @param collection The collection to initialize
* @param source The originating session
* @return true if we were able to initialize the collection from the cache;
* false otherwise.
*/
private boolean initializeCollectionFromCache(Serializable id, CollectionPersister persister, PersistentCollection collection, SessionImplementor source) {
...
if ( !source.getLoadQueryInfluencers().getEnabledFilters().isEmpty() && persister.isAffectedByEnabledFilters( source ) ) {
LOG.trace( "Disregarding cached version (if any) of collection due to enabled filters" );
return false;
}
...
}
{code}
Could you add this feature ?
For example, we should modify the cache key to add the filter name.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years
[Hibernate-JIRA] Created: (HBX-1199) Missing support for n-Types
by Haug Bürger (JIRA)
Missing support for n-Types
---------------------------
Key: HBX-1199
URL: https://hibernate.onjira.com/browse/HBX-1199
Project: Hibernate Tools
Issue Type: Bug
Components: reverse-engineer
Affects Versions: 3.2.cr1
Reporter: Haug Bürger
org.hibernate.cfg.reveng.JDBCToHibernateTypeHelper
...
// length is for string column
public static boolean typeHasLength(int sqlType) {
return (sqlType == Types.CHAR || sqlType == Types.DATE
|| sqlType == Types.LONGVARCHAR || sqlType == Types.TIME || sqlType == Types.TIMESTAMP
|| sqlType == Types.VARCHAR );
}
I think the following line is missing:
|| sqlType == Types.NCHAR || sqlType == Types.NVARCHAR || sqlType == Types.NCLOB
I think that this makes the reverse engineer fail to add the length attribute if the column type is nvarchar. If a column is varchar the following xml is generated:
{{<property name="my_column" type="java.lang.String"><column name="MY_COLUMN" length="50" /></property>}}
If a column is nvarchar the following xml is generated:
{{<property name="my_column" type="java.lang.String"><column name="MY_COLUMN" /></property>}}
This is relevant in case you use the length attribute to validate the columns in your application.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years