[Hibernate-JIRA] Created: (HHH-2447) Connection leak if logAndClearWarnings throws
by Jeppe N. Madsen (JIRA)
Connection leak if logAndClearWarnings throws
----------------------------------------------
Key: HHH-2447
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2447
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3, 3.2.2
Environment: Database product name : DB2/NT
Database product version : SQL08025
JDBC driver name : IBM DB2 JDBC Universal Driver Architecture
Hibernate 3.1.3 (seems to exist in 3.2.2 as well)
JDBC driver version : 2.9.31
Reporter: Jeppe N. Madsen
Priority: Minor
In ConnectionManager.closeConnection, logAndClearWarnings is called before connection.close() is called. If this call throws an exception, the connection is never closed.
We have observed that DB2 sometimes throws an Error because the SQLWarning chain is wrong:
[14-02-07 11:36:30:889 CET] 10b0b533 WebGroup E SRVE0026E: [Servlet Error]-[SQLWarning chain holds value that is not a SQLWarning]: java.lang.Error: SQLWarning chain holds value that is not a SQLWarning
at java.sql.SQLWarning.getNextWarning(SQLWarning.java:109)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:50)
at org.hibernate.util.JDBCExceptionReporter.logWarnings(JDBCExceptionReporter.java:33)
at org.hibernate.util.JDBCExceptionReporter.logAndClearWarnings(JDBCExceptionReporter.java:22)
at org.hibernate.jdbc.ConnectionManager.closeConnection(ConnectionManager.java:443)
at org.hibernate.jdbc.ConnectionManager.cleanup(ConnectionManager.java:379)
at org.hibernate.jdbc.ConnectionManager.close(ConnectionManager.java:318)
at org.hibernate.impl.SessionImpl.close(SessionImpl.java:293)
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-6143) ElementCollection in Embeddable in Entity is ignored on merge
by Andy Schlaikjer (JIRA)
ElementCollection in Embeddable in Entity is ignored on merge
-------------------------------------------------------------
Key: HHH-6143
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6143
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.3
Environment: Hibernate EntityManager 3.6.3, HSQLDB 2.0.0
Reporter: Andy Schlaikjer
Attachments: merge-embedded-elementcollection.zip
*Overview*
When an {{@ElementCollection}} field {{ec}} is defined within an {{@Embeddable}} type {{C}}, and an {{@Embedded}} field {{em}} of type {{C}} is defined within an {{@Entity}} type {{E}}, if we create an {{E}} instance {{e}} and initialize {{e.em.ec}}, the value of {{e.em.ec}} is ignored on merge of {{e}}. Furthermore, the value is ignored even when {{ec}} has been annotated with {{@ElementCollection(fetch = FetchType.EAGER)}} and Hibernate's {{@Cascade(ALL)}}, and {{em}} has been annotated with {{@Cascade(ALL)}}.
Disclaimer: This use case may not be required by the JPA 2.0 spec (though it'd be nice to see support):
{quote}
Implementations are not required to support embedded objects that are mapped across more than one table (e.g., split across primary and secondary tables or multiple secondary tables).
{quote}
Note: This issue may be related to HHH-5187, HHH-4135.
*Steps to reproduce*
# Define {{@Embeddable}} type {{ContactInfo}} with {{@ElementCollection}} field {{emailAddresses}} of type {{List<String>}}.
# Define {{@Entity}} type {{Person}} with {{@Embedded}} field {{contactInfo}} of type {{ContactInfo}}.
# Create a new {{Person}} instance {{p1}} and initialize {{p1.contactInfo.emailAddresses}}.
# Use {{EntityManager}} to merge {{p1}}.
# Use {{EntityManager}} to find {{Person}} with id matching that of {{p1}}; Init {{p2}} with result.
# Compare {{p1}} and {{p2}}.
.
*Expected*
{{Person}} instances {{p1}} and {{p2}} are identical. Specifically, {{p2.contactInfo.emailAddresses}} should not be null, and its contents should match that of {{p1.contactInfo.emailAddresses}}.
*Observed*
{{Person}} instances {{p1}} and {{p2}} are not equal: {{p2.contactInfo.emailAddresses}} is null. On merge of {{p1}} Hibernate is ignoring non-null {{p1.contactInfo.emailAddresses}} property value. From the source code, it looks like the {{p1.contactInfo.emailAddresses}} property value is not being copied into the EntityManager's managed instance of {{p1}} on merge.
*Test case*
Please see the attached Maven project for full unit test.
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-4015) one-to-one: foreign key: save Problem
by Sandeep Vaid (JIRA)
one-to-one: foreign key: save Problem
-------------------------------------
Key: HHH-4015
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4015
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.6
Reporter: Sandeep Vaid
Priority: Critical
I have one-to-one relationship between class A and class B
<class name="A" table="TEMPA" >
<id name="aaId" type="string" column="AID" length="10">
<generator class="assigned"></generator>
</id>
<one-to-one name="b" class="B" constrained="true" outer-join="false" cascade="save-update" />
</class>
<class name="B" table="TEMPB" lazy="true">
<id name="baId" type="string" column="BID" length="10">
<generator class="foreign">
<param name="property">a</param>
</generator>
</id>
<one-to-one name="a" class="A" />
</class>
Problem 1: When i try to save A, it fires :
insert into HBLEARN1.TEMPB (BID) values ('1')
and throws error :
The insert or update value of the FOREIGN KEY "TEMPB.CC1246876555824" is not equal to any value of the
parent key of the parent table. SQLSTATE=23503
Why it is first trying to save 'B' instead of 'A' first ?
Problem 2: With this mapping, if i set <property name="hibernate.hbm2ddl.auto">create</property> in hibernate.cfg.xml,
It generates TEMPA whose aaId is the foreign key referencing TEMPB. This is also incorrect..
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush
by Josh Moore (JIRA)
many-to-one in a properties element causes strange PropertyValueException on flush
----------------------------------------------------------------------------------
Key: HHH-2075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: HSQLDB
Hibernate r10478
Reporter: Josh Moore
Attachments: exception.txt, log.txt, properties.zip
Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case.
<code>
Image i = new Image();
Pixels p = new Pixels();
p.setSizeC(new Integer(2));
p.setImage(i); // This calls i.getPixels().add(p)
// i.setPixels(null); // This makes it work.
Session s = openSession();
Transaction t = s.beginTransaction();
// s.merge(i); // This makes it work.
p = (Pixels) s.merge(p); // This fails with the exception below.
t.commit();
s.close();
</code>
The properties element in question is:
<code>
<properties name="defaultPixelsTag">
<property name="defaultPixels" type="java.lang.Boolean"/>
<many-to-one name="image" class="Image" column="image"
not-null="true" unique="false" insert="true" update="true"
cascade="lock,merge,persist,replicate,refresh,save-update"
/>
</properties>
</code>
The reverse side is:
<code>
<set
name="pixels"
lazy="true"
inverse="true"
cascade="lock,merge,persist,replicate,refresh,save-update">
<key column="image" not-null="false"/>
<one-to-many class="Pixels"/>
</set>
</code>
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
by Paul Cowan (JIRA)
Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
--------------------------------------------------------------------------------
Key: HHH-3102
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Reporter: Paul Cowan
Priority: Minor
Attachments: HibernateKeyPoolTest.java
Hi all,
Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though.
Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool.
A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows:
*** After creation
Mouth (id=null) has teeth [canine(id=null)]
*** Save
Mouth (id=1) has teeth [canine(id=2)]
*** Flush
Hibernate: insert into Mouth (id) values (?)
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2)]
*** Add new
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Save again
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Flush again
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2), molar(id=3)]
As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good.
However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed.
While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not.
There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent.
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-5945) Race condition in building query cache
by Luca Domenichini (JIRA)
Race condition in building query cache
--------------------------------------
Key: HHH-5945
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5945
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.6.1
Environment: Hibernate 3.6.1, EhCache 2.3.0..2.3.2, MSSQL 2005 Developer Edition
Reporter: Luca Domenichini
I have this sample program that creates 10 threads that executes the same cached query in a thread-local current session context. Entity ClasseAltezza is a READ_ONLY cached entity.
{panel}{noformat}
public static void main(String[] args) {
List<Thread> threads = new ArrayList<Thread>();
for (int i=0; i<10; i++) {
Thread t = new Thread() {
@Override
public void run() {
try {
HibernateUtil.beginTransaction();
HibernateUtil.getCurrentSession()
.createCriteria(ClasseAltezza.class)
.setCacheable(true)
.setCacheRegion(ClasseAltezza.class.toString())
.list();
HibernateUtil.commitTransaction();
}
catch (Exception ex) {
ex.printStackTrace();
HibernateUtil.rollbackTransaction();
}
}
};
threads.add(t);
}
for (Thread t : threads)
t.start();
}
{noformat}{panel}
This is the output:
{panel}{noformat}org.hibernate.cache.CacheException: net.sf.ehcache.ObjectExistsException: Cache class com.promag.wms.base.persistence.entities.ClasseAltezza already exists
at org.hibernate.cache.EhCacheProvider.buildCache(EhCacheProvider.java:101)
at org.hibernate.cache.impl.bridge.RegionFactoryCacheProviderBridge.buildQueryResultsRegion(RegionFactoryCacheProviderBridge.java:115)
at org.hibernate.cache.StandardQueryCache.<init>(StandardQueryCache.java:78)
at org.hibernate.cache.StandardQueryCacheFactory.getQueryCache(StandardQueryCacheFactory.java:44)
at org.hibernate.impl.SessionFactoryImpl.getQueryCache(SessionFactoryImpl.java:1173)
at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2285)
at org.hibernate.loader.Loader.list(Loader.java:2268)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:119)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1716)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:347)
at com.promag.wms.base.persistence.methods.ClasseAltezzaMethods.getAll(ClasseAltezzaMethods.java:30)
at Test$1.run(Test.java:20)
Caused by: net.sf.ehcache.ObjectExistsException: Cache class com.promag.wms.base.persistence.entities.ClasseAltezza already exists
at net.sf.ehcache.CacheManager.addCache(CacheManager.java:888)
at org.hibernate.cache.EhCacheProvider.buildCache(EhCacheProvider.java:94)
... 11 more
{noformat}{panel}
I see that in Hibernate 3.6.0 there were a synchronized block in method SessionFactory.getQueryCache(String regionName) the prevented the same query region to be built twice as it happens in Hibernate 3.6.1, were the synchronized block is missing..
This is the method in SessionFactoryImpl:
{panel}{noformat}
public QueryCache getQueryCache(String regionName) throws HibernateException {
if ( regionName == null ) {
return getQueryCache();
}
if ( !settings.isQueryCacheEnabled() ) {
return null;
}
synchronized ( allCacheRegions ) { // THIS SYNCHRONIZED IS MISSING IN 3.6.1!!!!
QueryCache currentQueryCache = ( QueryCache ) queryCaches.get( regionName );
if ( currentQueryCache == null ) {
currentQueryCache = settings.getQueryCacheFactory().getQueryCache( regionName, updateTimestampsCache, settings, properties );
queryCaches.put( regionName, currentQueryCache );
allCacheRegions.put( currentQueryCache.getRegion().getName(), currentQueryCache.getRegion() );
}
return currentQueryCache;
}
}
{noformat}{panel}
--
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
12 years, 11 months
[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.
by Philip R. "Pib" Burns (JIRA)
Long "in" lists in queries results in a Java stack overflow exception.
----------------------------------------------------------------------
Key: HHH-2166
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris)
Reporter: Philip R. "Pib" Burns
Attachments: NodeTraverser.java
With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like
where x in (:x)
or a manually constructed
where x in (1,2,3 .....)
can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size.
The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times.
The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method.
--
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
12 years, 11 months