[Hibernate-JIRA] Created: (HHH-3576) out of memory
by sridhar (JIRA)
out of memory
-------------
Key: HHH-3576
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3576
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Environment: windows 2003 Standard edition SP2
Reporter: sridhar
Attachments: hibernate.zip
Hibernate unable to use scrollable results and running out of memory for MS SQL Server 2005 and MySQL 5.0.
But it is working fine for Oracle 10G.
Problem Description:
===================
I have a table with 10 columns and one of them is blob field. this blob field contains binary information about 33KB.
I have 70,000 rows in database.
When I read the complete data using scrollable results implementation of hibernate, for Oracle 10G, the process completeed in 10 Seconds.
But when run the same program for MS SQL Server 2005 and MySQL 5.0 its running out of memory.
Steps to reproduc the problem:
=========================
I am enclosing the eclipse project. In the lib folder it contains the JDBC drivers for Oracle 10G, Mysql 5, MS SQL Server2005.
Remaing jar files will come with standard Springs distribution of 2.5.
import the project into eclipse.
Please configure the database details in jdbc.properties
now run the DBRead.java.
This will populate the 68828 records in the configured database and reads complete data from the database.
For MySQL and MS SQl Server it will give out of memory error while reading.
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-2668) Caching Fails with Composite-Ids Containing Nested, Complex Entities
by Juan Osuna (JIRA)
Caching Fails with Composite-Ids Containing Nested, Complex Entities
--------------------------------------------------------------------
Key: HHH-2668
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2668
Project: Hibernate3
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.4.sp1
Environment: Problem is independent of environment or platform and most likely exists in prior versions.
Reporter: Juan Osuna
Attachments: hibernate-caching-fix.zip
Description of Failing Test Case Scenario
Preconditions: An entity class is mapped that uses a composite-id that contains a nested entity class. Only the composite-id class implements equals/hashcode, not the nested entity class.
Steps to Reproduce:
1. open session and fetch object using composite-id
2. open new session and fetch same object again using different instance of composite-id but with same identity
Invalid Postconditions: On second retrieve, Hibernate fails to get the object from the cache and unnecessarily reloads the object. CachKeys containing different instances of the composite-id always fail to be equal even though they have the same persistent identity.
Attachment Contents
Code fix is attached as well as a Junit test case that reproduces the problem and validates the fix. The full Hibernate suite was also executed with no impact.
Attachment contains:
New Test Method:
org.hibernate.test.cache.BaseCacheProviderTestCase.testQueryCacheComplexItem
New Test Entity Items:
org\hibernate\test\cache\ComplexItem.hbm.xml
org.hibernate.test.cache.ComplexItem
org.hibernate.test.cache.ComplexItemPK
Code Fix:
org.hibernate.cache.CacheKey (see FIX comments)
Problem and Fix Details
Hibernate generally strives to use persistent identifiers for managing object identity rather than the equals/hashcode methods implemented by entity classes. While it is good practice to implement equals/hashcode, Hibernate does not generally force users to do this.
When wrapping a composite-id object, the current implementation of CacheKey fails to recurse through nested complex entities to query for equality based on persistent identity. Instead, when the recursion algorithm hits a complex entity, it invokes equals directly on that entity rather than further recursing through the identifier object.
Notably, the recursion logic for equals is not symmetrical with the recursion logic for hashcode, which does recurse through identifier objects. So, while CacheKey never invokes hashcode on nested complex entities, it does invoke equals on these entities.
A simple fix to this inconsistency is to store the factory parameter passed to CacheKey and later pass that parameter to the overloaded method:
Type.isEqual(Object x, Object y, EntityMode entityMode, SessionFactoryImplementor factory).
This fix restores symmetry to equals and hashcode behavior. By calling this overloaded method, the thread of execution will enter EntityType. isEqual(Object x, Object y, EntityMode entityMode, SessionFactoryImplementor factory), which correctly recurses through complex identifiers.
Design Principles
Hibernate should strive to behave predictably even in scenarios where users do not follow best practices.
Hibernate should strive to be as forgiving as possible as long there is no negative consequence caused by such forgiveness.
Hibernate should behave as consistently as possible. If Hibernate does not generally rely user-implemented equals/hashcode, it is best to avoid exceptions to this rule wherever possible.
Possible Future Enhancement
Mapping composite-ids that contain complex entities can cause deep object graphs to be cached as part of CacheKey. This is unsettling because of it's potential to consume memory unnecessarily and unpredictably.
Currently, CacheKey caches the hashcode by recursing through a complex graph of identifier objects. Perhaps, it would also be possible for CacheKey to cache an object graph of identifier objects whose leaves hold primitive values. This would further add symmetry between hashcode and equals and lighten the load for caching composite-ids that hold entity classes.
Robustly supporting composite-ids that hold complex identifiers seems like a worthwhile design goal.
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-4057) Error occurs when the not-null column has a default value in the DB but the field in object has no default value.
by Rupesh Kumar (JIRA)
Error occurs when the not-null column has a default value in the DB but the field in object has no default value.
-----------------------------------------------------------------------------------------------------------------
Key: HHH-4057
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4057
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.2
Environment: Hibernate 3.3.2
Reporter: Rupesh Kumar
I have a column in the database which is not null and has a default value.
In the Java object, I don't have any default value set on the field mapped to this column. When this object is saved, Hibernate throws up an error because it tried to insert a null value in the not-null column. Since DB can generate the value for this column, hibernate should use that.
I can not use generated attribute in hibernate mapping file because this column value is not always generated. It is generated only when no value is specified for this column while inserting.
Hibernate should inspect the database and find out which columns has default value set on it. If there is anything set on it, insert should ignore the mapped field if the value is not defined for it.
--
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, 8 months
[Hibernate-JIRA] Created: (HHH-3817) JBC second level cache integration can cache collection data
by Brian Stansberry (JIRA)
JBC second level cache integration can cache collection data
------------------------------------------------------------
Key: HHH-3817
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3817
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.3.x
Scenario with two transactions dealing with a single collection:
tx1 reads collection, cache miss
tx1 goes to database to read collection
tx2 reads collection, cache miss
tx2 goes to database to read collection
tx2 does JBC putForExternalRead to store empty collection
tx2 updates collection
tx2 removes collection from JBC (since any collection update triggers a org.hibernate.cache.Cache.evict which is implemented as a JBC removeNode)
tx1 does JBC putForExternalRead to store empty collection -- STALE DATA
With entities, if the db is using REPEATABLE_READ this won't be a problem, as the DB won't allow the tx2 update until tx1 commits. With a collection there is nothing to lock on. It would be a problem for entities with READ_COMMITTED as well.
--
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, 8 months
[Hibernate-JIRA] Created: (ANN-660) HHH-2545 Alive
by Eugene Batogov (JIRA)
HHH-2545 Alive
--------------
Key: ANN-660
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-660
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Environment: Gentoo Linux x86
JDK: 1.6. SUN and BEA
JBoss-4.2.1.GA
Hibernate: 3.2.5
Annotation: 3.3.0.GA
EntityManager: 3.3.1
Reporter: Eugene Batogov
Priority: Critical
I have a same problem how in HHH-2545 bug !
I update Hibernate to 3.2.5, hibernate-annotation to 3.3.0.GA
hibernate-entitymanager to 3.3.1.GA.
But this bug alive!
I use ehcache-1.3.0. jBoss-4.2.1.GA.
My query, which get from cache with null elements in collections:
Long customerAccount = customerIdentity.getCustomerAccount().getId();
try{
String sql = "select npvr.npvrChannels from NpvrServiceSpec npvr"+
" where npvr.id in ("+
" select ss.id from Customer cust join cust.accounts acc join
cust.subscriptions sub"+
" join sub.serviceSpecifications ss"+
" where acc.id =:customerAccount and"+
" ss in (from NpvrServiceSpec))";
Query query = emanager.createQuery(sql);
query.setParameter("customerAccount", customerAccount);
query.setHint("org.hibernate.cacheRegion", "query.findQueryNpvrChannelsBySubsription");
query.setHint("org.hibernate.cacheable", true);
result = query.getResultList();
Help me, please !
Thanks in advance.
--
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, 8 months