[Hibernate-JIRA] Created: (HHH-2470) Use of session.createSQLQuery causes memory leak
by Bjørn Bjerkeli (JIRA)
Use of session.createSQLQuery causes memory leak
-------------------------------------------------
Key: HHH-2470
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2470
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.1.3
Environment: Win XP, Oracle 10g, Java 1.4.2
Reporter: Bjørn Bjerkeli
Attachments: TestCase.zip
NativeSQLQuerySpecification fails to properly implement equals and hashcode caused by lacking implementation of hashCode and equals in all SQLQueryReturn implementations and SQLQueryScalarReturn which are members of NativeSQLQuerySpecification. I can see that NativeSQLQuerySpecification has been changed in 3.2, but the problem is still there.
NativeSQLQuerySpecification instances are used as keys for retrieving and caching NativeSQLQueryPlan instances.
This causes the caching-mechanism to be pretty useless when Queries created by session.createSQLQuery because new entries will be added all the time in the QueryPlanCache and the SoftLimitMRUCache member.
So far so good, the more serious problem that is caused by this is stems from the implementation of SoftLimitMRUCache which again uses LRUMap in commons-collection. The put - method of the cache is not treadsafe, and that causes the following fragment in LRUMap to allow the map to grow beyond its maximumSize. That is bacause the containsKey method will return an incorrect result when concurrently updating the map.
public Object put( Object key, Object value ) {
int mapSize = size();
Object retval = null;
if ( mapSize >= maximumSize ) {
// don't retire LRU if you are just
// updating an existing key
if (!containsKey(key)) {
// lets retire the least recently used item in the cache
removeLRU();
}
}
retval = super.put(key,value);
return retval;
}
I have included a test-case that demonstrates:
1) Wrong implementation of equals and hashCode in NativeSQLQuerySpecification
2) Concurrent use of LRUMap causes the map to grow beyound it's max limit
3) Concurrent execution of session.createSQLQuery causes memory leak due to 1) and 2)
I would be more than happy to contribute to get this fixed. Just let me know.
--
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
13 years, 11 months
[Hibernate-JIRA] Created: (HHH-2339) merge instumented class fails
by Alexey Romanchuk (JIRA)
merge instumented class fails
-----------------------------
Key: HHH-2339
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2339
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.0.ga
Environment: Hibernate 3.2.1 (tested with 3.2.0 too)
Postgresql 8.1.4
Reporter: Alexey Romanchuk
Priority: Blocker
When we try to merge instrumented detached entity with lazy no-proxy many-to-one association we have org.hibernate.LazyInitializationException.
It occurs because cascade try to process all associations in Cascade class, but object disconected from session and can not obtaion lazy property.
If classes are not instrumented all works ok.
Why merge action does not have overrided performOnLazyProperty mathod to prevent fetching lazy properties?
Here it is small example that illustates problem.
===MAPPING===
<hibernate-mapping>
<class name="Client" table="test_client">
<id name="id" column="id" type="long">
<generator class="sequence">
<param name="sequence">test_seq</param>
</generator>
</id>
<property name="name" column="name"/>
<many-to-one name="info" class="LoginInfo" lazy="no-proxy" column="info_id" cascade="merge,evict"/>
</class>
<class name="LoginInfo" table="test_login_info">
<id name="id" column="id" type="long">
<generator class="sequence">
<param name="sequence">test_seq</param>
</generator>
</id>
<property name="login" column="login"/>
<property name="pass" column="pass"/>
</class>
</hibernate-mapping>
===JAVA===
===DOMAIN===
public class Client
{
private long id;
private String name;
private LoginInfo info;
//getters and setters
}
public class LoginInfo
{
private long id;
private String login;
private String pass;
//getters and setters
}
===USAGE===
public class Main
{
public static void main( String[] args )
{
Session s1 = sf.openSession();
s1.beginTransaction();
Client c = ( Client ) s1.get( Client.class, 2l );
s1.flush();
s1.getTransaction().commit();
s1.close();
Session s2 = sf.openSession();
s2.beginTransaction();
c = ( Client ) s2.merge( c );
s2.flush();
s2.getTransaction().commit();
s2.close();
}
}
==STACKTRACE===
org.hibernate.LazyInitializationException: session is not connected
at org.hibernate.intercept.AbstractFieldInterceptor.intercept(AbstractFieldInterceptor.java:67)
at org.hibernate.intercept.cglib.FieldInterceptorImpl.readObject(FieldInterceptorImpl.java:75)
at Client.$cglib_read_info(Client.java)
at Client.getInfo(Client.java:12)
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.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:145)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropertyValue(AbstractEntityTuplizer.java:277)
at org.hibernate.persister.entity.AbstractEntityPersister.getPropertyValue(AbstractEntityPersister.java:3529)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultMergeEventListener.cascadeOnMerge(DefaultMergeEventListener.java:407)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:266)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:120)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:53)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:677)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:661)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:665)
at Main.main(Main.java:56)
--
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
14 years
[Hibernate-JIRA] Created: (HHH-2388) Insert w/ identity column fails on Sybase but no exception occurs
by Tim Morrow (JIRA)
Insert w/ identity column fails on Sybase but no exception occurs
-----------------------------------------------------------------
Key: HHH-2388
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2388
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1.GA with annotations
Sybase jConnect 6.05 JDBC driver
Sybase ASE 15 database
Reporter: Tim Morrow
I have a scenario where storing a new entity fails (i.e. the row is not inserted) but Hibernate does not realize this. No exceptions are thrown. Later, this leads to AssertionFailures (if two such entities fail in the same session - they both have the same PK).
The problem specifically occurs with a table that has a numeric column with precision (e.g. numeric(10,4)) and an identity column when using Sybase ASE.
==========
To reproduce:
1. Use Sybase jConnect 6.05 JDBC driver with Sybase ASE 15 database.
2. Define an Entity with a long ID and BigDecimal numeric column.
3. Create a corresponding table with an identity column and numeric(10, 4) column.
For example:
hibernate.MyEntity.java:
-----------------------------------------
package hibernate;
import java.math.BigDecimal;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
import org.hibernate.validator.NotNull;
@Entity
@Table(name = "z_tim_test")
public class MyEntity {
private BigDecimal cost;
private long id;
public MyEntity() {}
@Column(columnDefinition = "numeric(10,4)")
@NotNull public final BigDecimal getCost() {
return cost;
}
@GeneratedValue(strategy = GenerationType.AUTO)
@Id public final long getId() {
return id;
}
public final void setCost(BigDecimal cost) {
this.cost = cost;
}
public final void setId(long id) {
this.id = id;
}
}
Table:
-----------------------------------------
CREATE TABLE z_tim_test
(
id numeric(19) PRIMARY KEY not null,
cost numeric(10,4) not null
);
4. Write some code that stores a new entity and tries to load it:
MyEntity myEntity = new MyEntity();
myEntity.setCost(new BigDecimal("123.12345"));
session.save(myEntity);
session.flush();
session.clear();
List<MyEntity> results = session.createCriteria(MyEntity.class).list();
if (results.size() != 1) {
throw new IllegalStateException("Expected 1 result");
}
This test will throw the IllegalStateException because the row was not persisted and no errors occurred.
Reason:
* Sybase does not thrown any SQLException when you try and persist a numeric value whose scale exceeds that defined on the column. Instead, it returns an updateCount of zero and an identity column value of zero.
* Hibernate does not check the updateCount after executing the statement when using an Identity column. The offending code is in:
org.hibernate.id.IdentityGenerator$InsertSelectDelegate
public Serializable executeAndExtract(PreparedStatement insert) throws SQLException {
if ( !insert.execute() ) {
while ( !insert.getMoreResults() && insert.getUpdateCount() != -1 ) {
// do nothing until we hit the rsult set containing the generated id
}
}
ResultSet rs = insert.getResultSet();
try {
return IdentifierGeneratorFactory.getGeneratedIdentity( rs, persister.getIdentifierType() );
}
finally {
rs.close();
}
}
It ignores the updateCount.
The net result is that the object is assigned a PK value of zero. Hibernate continues. My applicaiton is unaware that the row failed to insert.
Solution:
It would seem to me replacing the above code with:
if (!insert.execute()) {
if (insert.getUpdateCount() < 1) {
throw new HibernateException("No update occurred");
}
while (!insert.getMoreResults()) {
// do nothing until we hit the rsult set containing the generated id
}
}
Would take care of the problem?
--
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
14 years
[Hibernate-JIRA] Created: (HHH-1989) Deleted object remains referenced in 2nd level cache collections
by Justin Haddad (JIRA)
Deleted object remains referenced in 2nd level cache collections
----------------------------------------------------------------
Key: HHH-1989
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3
Reporter: Justin Haddad
This problem seems identical to issue NH-678. I have enabled caching for an one-to-many association. I use Ehcache. I have a test in which I load the parent object along with its collection. Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object):
aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1705)
(continues on)
I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion.
--
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
14 years
[Hibernate-JIRA] Created: (HHH-2645) Synchronization bottleneck in EntityModeToTuplizerMapping
by Erik Bergersjö (JIRA)
Synchronization bottleneck in EntityModeToTuplizerMapping
---------------------------------------------------------
Key: HHH-2645
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2645
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.3 (and later), Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10, Oracle 10g R2
Reporter: Erik Bergersjö
Priority: Minor
We have had a major performance bottleneck in EntityModeToTuplizerMapping with Hibernate version 3.2.3 and the code for that class in 3.2.4sp1 is unchanged. We have found a solution that solves the issue and would like to get it into the real version. I submitted to the user forum first and was asked to create a JIRA issue.
The problematic line is:
private final Map tuplizers = Collections.synchronizedMap( new SequencedHashMap() );
We have changed it to (using util.concurrent):
private final Map tuplizers = new EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap();
This change alone makes our use cases six times faster. The difference is that ConcurrentReaderHashMap handles concurrent readers much better, they don't have to wait for each other.
The problem occurs when a high number of threads try to initialize sets (see mapping below). A thread dump showed a high number of threads waiting for the same monitor, see partial stack trace below.
The code runs on Sun's JDK 1.4.2_12 (server VM) on SunOS 5.10 and the kernel spends a lot of time handling mutexes with the original implementation. That time disappears from the radar screen with the fixed version.
Example mapping for set:
[code]
<set name="lines" lazy="true" inverse="true" cascade="all-delete-orphan">
<key>
<column name="col1" not-null="true" />
<column name="col2" not-null="true" />
</key>
<one-to-many class="LineClass" />
</set>
[/code]
Stack trace (partial):
"Thread-108" prio=5 tid=0x05852e90 nid=0x103 waiting for monitor entry [0x3ed7e000..0x3ed7fc28]
at java.util.Collections$SynchronizedMap.get(Collections.java:1942)
- waiting to lock <0x89d30788> (a java.util.Collections$SynchronizedMap)
at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizerOrNull(EntityModeToTuplizerMapping.java:53)
at org.hibernate.tuple.EntityModeToTuplizerMapping.getTuplizer(EntityModeToTuplizerMapping.java:66)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:353)
at org.hibernate.type.ComponentType.isEqual(ComponentType.java:141)
at org.hibernate.engine.CollectionKey.equals(CollectionKey.java:50)
at java.util.HashMap.eq(HashMap.java:274)
at java.util.HashMap.get(HashMap.java:323)
at org.hibernate.engine.loading.CollectionLoadContext.getLocalLoadingCollectionEntry(CollectionLoadContext.java:163)
at org.hibernate.engine.loading.CollectionLoadContext.locateLoadingCollectionEntry(CollectionLoadContext.java:150)
at org.hibernate.engine.loading.CollectionLoadContext.getLoadingCollection(CollectionLoadContext.java:92)
at org.hibernate.loader.Loader.readCollectionElement(Loader.java:1003)
at org.hibernate.loader.Loader.readCollectionElements(Loader.java:646)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:591)
at org.hibernate.loader.Loader.doQuery(Loader.java:701)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236)
at org.hibernate.loader.Loader.loadCollection(Loader.java:1994)
at org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716)
at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344)
at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86)
at org.hibernate.collection.PersistentSet.iterator(PersistentSet.java:163)
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-2041) Update with unaltered natural-id fails
by Jim Pease (JIRA)
Update with unaltered natural-id fails
--------------------------------------
Key: HHH-2041
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2041
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: hibernate-3.1.3, mysql-4.1.12
Reporter: Jim Pease
This may be a duplicate of http://opensource.atlassian.com/projects/hibernate/browse/HHH-1574.
Getting following error:
caused by: org.hibernate.HibernateException: immutable natural identifier of an instance of edu.syr.lsb.gmt.impl.LinkImpl was altered
at org.hibernate.event.def.DefaultFlushEntityEventListener.checkNaturalId(DefaultFlushEntityEventListener.java:80)
at org.hibernate.event.def.DefaultFlushEntityEventListener.getValues(DefaultFlushEntityEventListener.java:155)
at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:106)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:195)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
...
This is occurring without modifications to the natural identifier, which is mapped as follows:
<natural-id>
<property name="activityRef" column="ACTIVITY_REF" length="255" not-null="true" />
<many-to-one name="goal" class="GoalImpl" column="GOAL_ID" not-null="true" cascade="none" />
</natural-id>
--
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
14 years, 1 month
[Hibernate-JIRA] Created: (HHH-2584) PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map
by Daniel Wellman (JIRA)
PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map
---------------------------------------------------------------------
Key: HHH-2584
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.3, 3.2.2, 3.2.1
Environment: Hibernate 3.2.3 ga, MySQL 5.0.24a, for Win32
Reporter: Daniel Wellman
Attachments: persistentmap_remove.patch
This problem is nearly identical to HHH-2476: PersistentMap.put() incorrect on uninitialized, non-extra-lazy map. remove() has the same problem. See also issue HHH-2142.
The write up for HHH-2476 was so concise that I will transform it here, substituting remove() for put().
---
Essentially, an uninitialized PersistentMap loses the first remove() into it if defined as non-extra-lazy.
The underlying cause is the code in PersistentMap#remove() which attempts to readElementByIndex(). In the case of non-extra-lazy, readElementByIndex() returns the UNKNOWN marker object which is supposed to be used to signal that the delegate map is now initialized and to remove the element directly from the map. Long story short, PersistentMap#remove() does not properly check the return value from readElementByIndex() and react accordingly.
--
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
14 years, 2 months