[Hibernate-JIRA] Created: (HHH-2146) NullpointerException in DefaultDeleteEventListener.deleteTransientEntity
by Martin Kartumovich (JIRA)
NullpointerException in DefaultDeleteEventListener.deleteTransientEntity
------------------------------------------------------------------------
Key: HHH-2146
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2146
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr5
Environment: Hibernate 3.2.0cr5, Oracle10g
Reporter: Martin Kartumovich
Priority: Blocker
The following setup leads to a NPE in DefaultDeleteEventListener.deleteTransientEntity:
Tables A, B
Table V_A_B that is an M-N-Connection between A and B.
Pojo for A has a Set of V_A_Bs.
Pojo for B has a Set of V_A_Bs.
Pojo C that has Sets of As and Bs.
Cascades: all, delete-orphan
-Create a new A and add a new V_A_B to its Set, that references to an existing B.
-Delete B.
-SaveOrUpdate Pojo C.
In Hibernate 3.1.3 this works fine.
In 3.2.0cr4+cr5 the removal of B results into an cascading removal of the never persisted V_A_B in the Set of B instead of ignoring it.
This leads to an incorrect state where deleteTransientEntity is called with transientEnties=null.
When now calling transientEnties.contains(...) the NPE is thrown.
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-2399) FlushMode.AUTO practically unusable - should not flush before EVERY query
by Piotr Kołaczkowski (JIRA)
FlushMode.AUTO practically unusable - should not flush before EVERY query
-------------------------------------------------------------------------
Key: HHH-2399
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399
Project: Hibernate3
Type: Improvement
Versions: 3.1.3, 3.2.1, 3.2.2, 3.2.0.ga
Environment: PostgreSQL 8.1.5, JDBC 2 and 3, Linux kernel 2.4.x, 2.6.x, Java 1.5.0_09
Reporter: Piotr Kołaczkowski
Attachments: hbtest.zip
The method flushIfRequired seems to flush before every query execution, even though there wasn't anything changed to the objects in the session, and the objects in the session are of different class than the object(s) queried. When having more than a few such objects in a session, it may lead to large, unneeded overheads (I noticed 10-200 times slowdown on simple queries). Our system uses many fast queries, that uasually return only one result or few results. The average query durations on different levels, measured by System.nanoTime() (see the attachment):
- database level: 0.05 ms
- pure JDBC code, prepared statements: 0.2 ms
- pure JDBC code, no prepared statements: 0.7 ms
- not cached hibernate query, no other objects associated with the session: 1.3 ms
- cached hibernate query, object in the session cache, no other objects associated with the session: 1.1 ms
- cached hibernate query, 10000 very simple objects of some other class in the session: >50 ms
10000 may seem large, but note these were very simple objects, having only 2 properties. On our production system we have classes with many properties, and even 20 objects in a session can cause a sub-millisecond query to run longer than 5 ms. We switched to FlushMode.COMMIT, and now the performance is much better.
Can you do something about this? As far as I've read in JIRA, a similar issue exists in Hibernate 2.x, and is still OPEN / UNRESOLVED.
BTW. Why is the 1st level cache so slow in my tests? Why reading just a 2 field object from the database cause so much overhead over pure JDBC? What am I doing wrong?
There is so much marketing about using cglib reflection optimizer in the performance FAQ but even if I retrieved these objects using JDBC and reflection, I would achieve much better performance. After all 1 ms is very much time, if getting results from DB and sending them to JVM lasts 0.2 ms.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2347) Improvement to DerbyDialect default identy generation mode
by Fabrizio Giustina (JIRA)
Improvement to DerbyDialect default identy generation mode
----------------------------------------------------------
Key: HHH-2347
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2347
Project: Hibernate3
Type: Patch
Versions: 3.2.1
Reporter: Fabrizio Giustina
Attachments: DerbyDialect-identity.diff
although derby supports identities org.hibernate.dialect.DerbyDialect strangely uses an HiLo generation strategy for ids (for any other dialects that support identities IdentityGenerator is the default).
Even more curiously, DerbyDialect overrides getIdentityColumnString() from the Db2 dialect by using "generated ALWAYS as identity" instead of "generated BY DEFAULT as identity". Derby however fully supports "by default" in identities as clarified in http://db.apache.org/derby/docs/10.1/ref/rrefsqlj37836.html .
"by default" should be preferred since it allows a direct insertion when needed (and I can't see no reason why enabling it for db2 and not for derby).
The patch attached simply deletes two methods, so that the default implementation from Db2Dialect is used:
- removing getIdentityColumnString() make derby use "by default" identities like db2 already does
- removing getNativeIdentifierGeneratorClass() make it choose IdentityGenerator.class (it falls back to the default strategy used in org.hibernate.dialect.Dialect)
note that part of this issue has already been reported in HHH-1918 (not addressing the identity generation string)
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2413) Offer a way to log bound jdbc parameters in a uniform way for UserType implementors
by Baptiste MATHUS (JIRA)
Offer a way to log bound jdbc parameters in a uniform way for UserType implementors
-----------------------------------------------------------------------------------
Key: HHH-2413
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2413
Project: Hibernate3
Type: Improvement
Versions: 3.2.2
Reporter: Baptiste MATHUS
Priority: Minor
At the moment, when someone implements a UserType, the bound parameters won't be displayed in not explicitly displayed via loggers.
For example, here is what the code of NullableType.nullSafeGet() is :
public final void nullSafeSet(PreparedStatement st, Object value, int index)
throws HibernateException, SQLException {
try {
if ( value == null ) {
if ( IS_TRACE_ENABLED ) {
log().trace( "binding null to parameter: " + index );
}
st.setNull( index, sqlType() );
}
else {
if ( IS_TRACE_ENABLED ) {
log().trace( "binding '" + toString( value ) + "' to parameter: " + index );
}
set( st, value, index );
}
}
catch ( RuntimeException re ) {
log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + re.getMessage() );
throw re;
}
catch ( SQLException se ) {
log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + se.getMessage() );
throw se;
}
}
IMO, it would be quite a good thing to provide some method in Hibernate, something like logBoundParameter() that would do the log like above :
> log().trace( "binding '" + toString( value ) + "' to parameter: " + index );
This method could then be just called by implementors so as to guaranty the display is always the same about bound parameters.
Even more, I think it should use a special logger, just like the org.hibernate.SQL one to display this parameters. In fact, at the moment, I feel the reference documentation is not very clear about this : see http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat.... It says :
> org.hibernate.type Log all JDBC parameters
But that's not completely true: it will only log bound parameters that are parameters typed with standard types coming from the org.hibernate.type package. Any custom UserType won't display anything until you:
1) put the right log4j line for the package where your userType is located ;
2) think about explicitly logging those parameter values in your custom UserType (cf. my first point).
I'm not sure I made myself totally clear,. If so, please let me know.
If you think that would be worth an improvement, I'll give a look to provide a patch for this. Thanks a lot.
--
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, 4 months
[Hibernate-JIRA] Created: (HHH-2272) Serious performance problems when saving large amount of transient entities with collections of transient entities
by Markus Heiden (JIRA)
Serious performance problems when saving large amount of transient entities with collections of transient entities
------------------------------------------------------------------------------------------------------------------
Key: HHH-2272
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2272
Project: Hibernate3
Type: Task
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0 on Oracle 9.2
Reporter: Markus Heiden
When saving many (e.g. 50000) transient entities with a collection of transient entities, for each collection element the whole persistence context is searched (by StatefulPersistenceContext#getIndexInOwner() and StatefulPersistenceContext#getOwnerId) and its even searched twice when the collection is an indexed collection. This leads to an enormous amount (> 1000000) of iterations over all entities and over all collection elements of each entity. Especially when one saves only the same type of entities this leads to times of hours(!) even on a fast machine before any insert statement is even issued. This issue is related to HHH-1612, but fixing issue HHH-1612 won't resolve this problem (I have explored this with a hack which fixes HHH-1612).
In my eyes there are two ways to solve this problem:
1) When cascading the save of a parent, the parent cascade can fill the persistence context with information about its collection elements. E.g. before cascading the save to a collection a parent can add a (child, parent) pair to a map in the persistence context to avoid the above described iterations. Then a simple Map#get() would be sufficient in most cases to get the parent.
2) When cascading, the parent has to be passed with the cascaded (e.g. saved) element. But this is no good solution, because it affects some well known hibernate apis.
--
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, 4 months
[Hibernate-JIRA] Created: (EJB-272) PostRemove being called before entity is actually deleted
by Paul (JIRA)
PostRemove being called before entity is actually deleted
---------------------------------------------------------
Key: EJB-272
URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-272
Project: Hibernate Entity Manager
Type: Bug
Versions: 3.2.1
Environment: Hibernate 3.2.1GA Entity Manager
Hibernate core 3.2.2 GA
Oracle 9i
Windows XP professional service pack 2
No application server is being used.
Reporter: Paul
I have an EntityListener with a method annotated with postremove. It seems that the method is being called before the actual entity is deleted from the database. When configuring log4j with "debug" logging it appears that the method is being called after the PreparedStatement is created and configured but before executeUpdate() is called.
I see the following statements in my log file before my listener is called
14:06:27,024 DEBUG AbstractBatcher:476 - preparing statement
14:06:27,024 DEBUG IntegerType:133 - binding '59532' to parameter: 1
My listener is called next. Then, the prepared statement is executed.
This violates the EJB3 spec. The EJB3 spec states "The PostPersist and PostRemove methods will be invoked after the
database insert and delete operations respectively."
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2142) PersistentMap.put(), remove() may return UNKNOWN object that can cause ClassCastException in client code
by Andrzej Miazga (JIRA)
PersistentMap.put(), remove() may return UNKNOWN object that can cause ClassCastException in client code
--------------------------------------------------------------------------------------------------------
Key: HHH-2142
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2142
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr5
Reporter: Andrzej Miazga
Here is some code in Hibernate 3.2.0cr5 that may cause this behaviour. I'm not sure if this is a bug but it surely affects the client code.
AbstractPersistentCollection:
protected Object readElementByIndex(Object index) {
if (!initialized) {
...
return persister.getElementByIndex( entry.getLoadedKey(), index, session, owner );
}
...
return UNKNOWN;
}
PersistentMap (extends AbstractPersistentCollection):
public Object put(Object key, Object value) {
if ( isPutQueueEnabled() ) {
Object old = readElementByIndex( key );
queueOperation( new Put( key, value, old ) );
return old;
}
...
So, there is a possibility to return UNKNOWN instance (MarkerObject) to the client code as the result of Map.put().
In version 3.1.3 this worked fine, but the implementation was different:
public Object put(Object key, Object value) {
Object old = isPutQueueEnabled() ?
readElementByIndex(key) : UNKNOWN;
if ( old==UNKNOWN ) {
write();
return map.put(key, value);
}
...
}
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2421) Cascading Delete In Wrong Order
by CannonBall (JIRA)
Cascading Delete In Wrong Order
-------------------------------
Key: HHH-2421
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2421
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Java5, MySQL 5 (InnoDB)
Reporter: CannonBall
Priority: Trivial
Mapping Document:
<hibernate-mapping>
<class name="scratchpad.hibernate.A">
<id name="id">
<generator class="increment"/>
</id>
<list name="bs" cascade="all,delete-orphan">
<key column="bId"/>
<list-index column="idx"/>
<one-to-many class="scratchpad.hibernate.B"/>
</list>
</class>
<class name="scratchpad.hibernate.B">
<id name="id">
<generator class="increment"/>
</id>
<many-to-one name="a" column="aId" insert="false" update="false"/>
<many-to-one name="c" column="cId" not-null="false"/>
</class>
<class name="scratchpad.hibernate.C">
<id name="id">
<generator class="increment"/>
</id>
</class>
</hibernate-mapping>
Code between sessionFactory.openSession() and session.close():
long id;
SessionFactory factory = new Configuration().configure()
.buildSessionFactory();
try {
Session s = factory.openSession();
try {
Transaction tx = s.beginTransaction();
try {
C c = new C();
s.save(c);
B b = new B();
b.setC(c);
A a = new A();
a.getBs().add(b);
s.save(a);
tx.commit();
id = b.getId();
} catch (Exception e) {
try {
tx.rollback();
} catch (Exception e2) {
// do nothing
}
throw e;
}
} finally {
s.close();
}
s = factory.openSession();
try {
Transaction tx = s.beginTransaction();
try {
A a = (A) s.load(A.class, id);
B b = a.getBs().get(0);
a.getBs().remove(b);
s.delete(b.getC());
tx.commit();
} catch (Exception e) {
try {
tx.rollback();
} catch (Exception e2) {
// do nothing
}
throw e;
}
} finally {
s.close();
}
} finally {
factory.close();
}
The generated SQL (show_sql=true):
Hibernate: select max(id) from C
Hibernate: select max(id) from A
Hibernate: select max(id) from B
Hibernate: insert into C (id) values (?)
Hibernate: insert into A (id) values (?)
Hibernate: insert into B (cId, id) values (?, ?)
Hibernate: update B set bId=?, idx=? where id=?
Hibernate: select a0_.id as id0_0_ from A a0_ where a0_.id=?
Hibernate: select bs0_.bId as bId1_, bs0_.id as id1_, bs0_.idx as idx1_, bs0_.id as id1_0_, bs0_.aId as aId1_0_, bs0_.cId as cId1_0_ from B bs0_ where bs0_.bId=?
Hibernate: select c0_.id as id2_0_ from C c0_ where c0_.id=?
Hibernate: update B set cId=? where id=?
Hibernate: update B set bId=null, idx=null where bId=?
Hibernate: delete from C where id=?
Hibernate: delete from B where id=?
When you have a collection that is mapped with a cascade of 'delete-orphan', when removing an entity from the collection, the corresponding orphan delete is scheduled at the end of the session's deletions queue. As you can see from my example above, when you have a relationship of A has a list of B's, B has a relationship with C, removing B from the A's list results in its deletion after C's deletion (despite the order of statements dictating C's deletion after B's). If I were to make B's relationship to C not-null, the above code would result in a FK constraint error as C would be removed before B.
You could force the correct removal of B before C with a manual delete of B like so:
A a = (A) s.load(A.class, id);
B b = a.getBs().get(0);
C c = b.getC();
a.getBs().remove(b);
s.delete(b);
s.delete(c);
--
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, 5 months