July 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5565) Memory leak is possible if changes for audited entities are outside of transaction

by Eugene Goroschenya (JIRA)

Memory leak is possible if changes for audited entities are outside of transaction ---------------------------------------------------------------------------------- Key: HHH-5565 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5565 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.1 Environment: hibernate-core-3.3.1.GA.jar, jboss-envers-1.2.1-hibernate-3.3.jar Reporter: Eugene Goroschenya Envers always collects changes for audited objects in global (global per sessionFactory instance) application map (auditConfiguration.auditSyncManager.auditSyncs<Transaction, AuditSync>) even if transaction is inactive. It leads to memory leak in application if there were changes (insert/update/delete) for versioned objects outside of transaction (transaction.isActive() == false) because in this case transaction is not committed where collected changes for current transaction are removed from global map. Possible solution is patch Envers to check if transaction is active (AuditEventListener in onPostInsert/onPostUpdate/onPostDeleteonCollectionAction methods) before starting collect changes for audited object. Skip collecting (to prevent memory leak) if transaction is inactive and log WARN message to indicate problem ("Couldn't create revision for entity ${entityName} because transaction is not active.") -- 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

11 years, 10 months

5
8
0 / 0

[Hibernate-JIRA] (HHH-7431) Reduce NaturalIdCacheKey Memory Footprint

by Eric Dalquist (JIRA)

11 years, 10 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5411) Missing value in not updatable column in Envers audit table

by Laurent Grangier (JIRA)

Missing value in not updatable column in Envers audit table ----------------------------------------------------------- Key: HHH-5411 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5411 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.0.GA Environment: Hibernate 3.4 Reporter: Laurent Grangier When I update an entity with a property which is updatable=false and that the property is not filled when passing the object to Hibernate, the update is correctly made by Hibernate but Envers fill a null value in the given column in the audit table. Example : {code} public class MyEntity { private String myString; @Column(updatable = false) private Long myLong; (...) } MyEntity entity = new MyEntity(); entity.setMyString("example"); entity.setMyLong(123L); entityManager.persist(entity); Long entityId = entity.getId(); (...) MyEntity entity = new MyEntity(); entity.setId(entityId); entity.setMyString("new value"); entityManager.persist(entity); // Here Envers miss to fill the column myLong in the audit table ! {code} In the above example, in the audit table, the value of "myLong" will be "null" but I expected "123" instead. -- 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

11 years, 10 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7311) NullPointerException if TenantConnectionProvider class does not exist

by Oriel Maute (JIRA)

NullPointerException if TenantConnectionProvider class does not exist --------------------------------------------------------------------- Key: HHH-7311 URL: https://hibernate.onjira.com/browse/HHH-7311 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Environment: Hibernate 4.1.2, using JPA Reporter: Oriel Maute Priority: Trivial Im using schema based multi tenancy. If i define a "hibernate.multi_tenant_connection_provider" which classfile does not exist in persistence.xml, a NullPointerException come up: <property name="hibernate.multi_tenant_connection_provider" value="com.xoricon.framework.server.jpa.tenant.TenantConnectionProvider"/> Class "com.xoricon.framework.server.jpa.tenant.TenantConnectionProvider" does not exist on classpath. Result: 1) testTreeOrder(com.xoricon.persistence.bo.multitenancy.test.SchemaBasedMultiTenancyTest)java.lang.NullPointerException at org.hibernate.engine.jdbc.internal.JdbcServicesImpl$MultiTenantConnectionProviderJdbcConnectionAccess.obtainConnection(JdbcServicesImpl.java:260) at org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:117) 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:2274) at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2270) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1739) at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:93) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:905) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:890) at org.hibernate.ejb.HibernatePersistence.createEntityManagerFactory(HibernatePersistence.java:57) at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:48) at com.xoricon.persistence.bo.test.AbstractTestCase.getEntityManagerFactory(AbstractTestCase.java:45) at com.xoricon.persistence.bo.multitenancy.test.SchemaBasedMultiTenancyTest.testTreeOrder(SchemaBasedMultiTenancyTest.java:42) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.xoricon.persistence.bo.multitenancy.test.SchemaBasedMultiTenancyTest.main(SchemaBasedMultiTenancyTest.java:53) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

3
2
0 / 0

[Hibernate-JIRA] (HHH-7382) refact: unify the configuration implementation loading strategy

by Strong Liu (JIRA)

11 years, 10 months

1
2
0 / 0

[Hibernate-JIRA] (HHH-7369) SQLServer2005Dialect: scalar query fails with pagination

by Strong Liu (JIRA)

11 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] (JPA-32) Setting cacheable="true" in orm.xml does not enable caching of entity in 2lc

by John O'Hara (JIRA)

11 years, 10 months

3
8
0 / 0

[Hibernate-JIRA] Created: (HHH-7310) Resolution of types registered in type registry does not work properly for Properties of @Embeddable types

by Chris Pheby (JIRA)

Resolution of types registered in type registry does not work properly for Properties of @Embeddable types ---------------------------------------------------------------------------------------------------------- Key: HHH-7310 URL: https://hibernate.onjira.com/browse/HHH-7310 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.3 Environment: Any Reporter: Chris Pheby The new type registry capability in Hibernate 4 and above is really useful. I have implemented an integrator that autoregisters some types, however what I have found is that whilst this works perfectly, the registered types are not being resolved correctly when they are used within @Embeddable classes. This is easily reproduced: for example, using Jadira Usertype (usertype.sourceforge.net), setting the system property to autoregister types and updating a test class to use @Embeddable triggers the problem. The problem occurs because the types are first initialised during a call to Configuration validate(). This occurs before any integrators are invoked and consequently types that will be mapped by the integrator at that time are mapped to either their existing basic type or Serializable. They are only remapped on future calls to getType on the type (such as within heuristic type). The resolution of the issue lies in removing the caching from Component because in the case of Component types these are not remapped on repeated calls to getType. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 10 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5929) PooledLoOptimizer in conjunction with SequenceStyleGenerator is not thread-safe

by Robin Sander (JIRA)

PooledLoOptimizer in conjunction with SequenceStyleGenerator is not thread-safe ------------------------------------------------------------------------------- Key: HHH-5929 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5929 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.1 Environment: Hibernate 3.6.1, Java 6, Mac OS 10.6.6 Reporter: Robin Sander The generate method of the PooledLoOptimizer introduced in 3.6.1 is not synchronized in difference to the one in PooledOptimizer and in other Optimizer implementations. The problem is that some IdentifierGenerator implementations have themselve a synchronized generate method (like SequenceHiLoGenerator e.g.) and some don't, like the new SequenceStyleGenerator. According to the javadoc IdentifierGenerator implementations have to be thread-safe. Now I don't know if there is any agreement among the developers whether this thread-safety is to be achieved in the IdentifierGenerator itself or in the Optimizer most of them delegate to but what I know is that SequenceStyleGenerator in conjunction with PooledLoOptimizer is not thread-safe because neither of them guards against concurrent access in any way. -- 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

11 years, 10 months

3
3
0 / 0

[Hibernate-JIRA] (HHH-7370) SQLServer2005Dialect: sql-transformation to common_table_expression not needed when offset = 0

by Strong Liu (JIRA)

11 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2012