[Hibernate-JIRA] Created: (HHH-3220) Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
by Dan Bisalputra (JIRA)
Patch to prevent "org.hibernate.AssertionFailure: possible non-threadsafe access to the session" error caused by stateless sessions
-----------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3220
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3220
Project: Hibernate3
Issue Type: Patch
Components: core
Affects Versions: 3.2.6
Environment: Hibernate 3.2.6, Apache Derby on Mac OSX & PC
Reporter: Dan Bisalputra
Priority: Minor
When performing a query in a stateless session, the query loads objects in a two-phase process in which a temporary persistence context is populated with empty objects in the first phase, then the objects' member data are read from the database in the second phase. If one of the objects contains an association or a collection, it performs a recursive call to the session's get() method. The get() method clears the temporary persistence context, so if the parent object contains any other associations to be read in the second phase, Hibernate throws an assertion because they are not found in the persistence context.
This patch solves the problem by only clearing the persistence context when the recursion ends. It passes all the unit tests for our application, but I have not tested it with any of the Hibernate unit tests.
--
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, 6 months
[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, 6 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, 7 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, 7 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, 7 months
[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete
by Markus Heiden (JIRA)
refresh throws exception when database has been altered with a delete
---------------------------------------------------------------------
Key: HHH-2305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle 9.2
Reporter: Markus Heiden
Attachments: hibernate.zip
First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead.
Test case is attached. Stacktrace of test case:
Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=?
org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003]
at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886)
at hibernate.refresh.Test.main(Test.java:46)
--
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, 7 months
[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data
by Manuel Dominguez Sarmiento (JIRA)
Custom Oracle Batcher to allow batch updates for versioned data
---------------------------------------------------------------
Key: HHH-3360
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga
Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work)
Reporter: Manuel Dominguez Sarmiento
Priority: Minor
Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java
We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates.
Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates.
We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection.
Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0.
A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface.
There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface.
Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#...
As expected, implementing this solution has resulted in drastical improvement in batch processing.
--
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, 7 months