[Hibernate-JIRA] Created: (HHH-3967) Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !!
by Guenther Demetz (JIRA)
Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !!
----------------------------------------------------------------------------
Key: HHH-3967
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3967
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Environment: 3.3.1 GA , SQLServer
Reporter: Guenther Demetz
Sometimes large stateful transactions are unavoidable and especially when having several large persistent collections in dirty state,
flushing becomes gradually more cpu intensive and slowly.
Analizing several stacktraces I detected that the thread most time is executing at the same point in reflection ,
see here a typical stacktrace:
java.lang.Class.isAssignableFrom(Native Method)
sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:36)
...
java.lang.reflect.Field.get(Field.java:358)
DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:55)
PojoEntityTuplizer(AbstractEntityTuplizer).getPropertyValue(Object, int) line: 300
SingleTableEntityPersister(AbstractEntityPersister).getPropertyValue(Object, int, EntityMode) line: 3609
Cascade.cascade(EntityPersister, Object, Object) line: 172
...
Making further investigations, I saw that:
- CascadingAction.PERSIST_ON_FLUSH requires NoCascadeChecking
- for all kind of properties the noCascade implementation is called
- regarding noCascade implementation checks only properties of type Entity !
public static final CascadingAction PERSIST_ON_FLUSH = new CascadingAction() {
...
public void noCascade(EventSource session, Object child, Object parent, EntityPersister persister, int propertyIndex) {
...
Type type = persister.getPropertyTypes()[propertyIndex];
if ( type.isEntityType() ) {
... check and throw eventually a TransientObjectException
}
}
Thus most property values are retrieved by reflection in vain as they are not of type entity.
With following code addition in org.hibernate.engine.Cascade.java
I was able do avoid most reflection method calls without affecting the behaviour:
org.hibernate.engine.Cascade.java
...
public void cascade(final EntityPersister persister, final Object parent, final Object anything) throws HibernateException {
...
else if ( action.requiresNoCascadeChecking() ) {
// Line:162
// begin Improvement
if (action == CascadingAction.PERSIST_ON_FLUSH) {
Type type = persister.getPropertyTypes()[i];
if ( !type.isEntityType() ) {
// Remark: goes only well as long PERSIST_ON_FLUSH noCascade implementation checks only entities
continue;
}
}
// end Improvement
action.noCascade(
eventSource,
persister.getPropertyValue( parent, i, entityMode ),
parent,
persister,
i
);
...
best regards
Guenther D.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3655) Select Query Using JPA and Static Inner Class
by Caine Lai (JIRA)
Select Query Using JPA and Static Inner Class
---------------------------------------------
Key: HHH-3655
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3655
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.3.1
Environment: Hibernate Version 3.3.1 GA, using JPA. MySQL DB.
Reporter: Caine Lai
Attachments: HibernateStaticInnerClassBug.zip
I want to collect some statistics using JPA and return them all as a value object to my web tier. In my value object I have a static inner class I would like to use for the JPA query.
My Class:
public class GeneralVendorStatsVO {
private List<StatusCounts> statusCounts = new ArrayList<StatusCounts>();
/**
* Inner class for holding status counts for vendors.
*/
public static class StatusCounts {
private UserStatus status;
private Long count;
public StatusCounts(UserStatus status, Long count) {
this.status = status;
this.count = count;
}
public UserStatus getStatus() { return status; }
public void setStatus(UserStatus status) { this.status = status; }
public Long getCount() { return count; }
public void setCount(Long count) { this.count = count; }
}
// ********************** Accessor Methods ********************** //
public List<StatusCounts> getStatusCounts() { return statusCounts; }
public void setStatusCounts(List<StatusCounts> statusCounts) { this.statusCounts = statusCounts; }
}
And here is the method I am trying to execute:
public GeneralVendorStatsVO getGeneralVendorStats() {
GeneralVendorStatsVO vo = new GeneralVendorStatsVO();
// Get the status counts.
String queryString = "SELECT new vo.stats.vendor.GeneralVendorStatsVO.StatusCounts(user.status, count(user)) FROM User user GROUP BY user.status";
Query query = this.em.createQuery(queryString);
List<GeneralVendorStatsVO.StatusCounts> statusCounts = query.getResultList();
vo.setStatusCounts(statusCounts);
for (GeneralVendorStatsVO.StatusCounts entry : statusCounts) {
log.debug("Status: " + entry.getStatus()+ "Count: " + entry.getCount());
}
return vo;
}
The error:
org.hibernate.hql.ast.QuerySyntaxException: Unable to locate class [vo.stats.vendor.GeneralVendorStatsVO.StatusCounts]
I don't know why this would not work, when I can do:
new GeneralVendorStatsVO.StatusCounts(UserStatus.APPROVED, 200L)
I was told I should open an issue because it seems like a bug. More info here: http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=78...
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2052) org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException
by Tree 'Huggy Bear' Hugger (JIRA)
org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException
-----------------------------------------------------------------------------------------------------------------------
Key: HHH-2052
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2052
Project: Hibernate3
Type: Bug
Reporter: Tree 'Huggy Bear' Hugger
Attachments: bugtest.zip
Debug level logging attempted by MessageHelper falls over when constructing a loggable string for a mapped collection on the main entity.
Following the code in the stacktrace, I can see that MessageHelper expects the parent key for the collection relationship to be the primary key, but it is mapped to another field of a different type via a property-ref. Hence the ClassCastException below.
The work around is to set logging to INFO or higher.
I have also attached a pared-down zip with the maven 2 project containing the mappings and the unit test which fails.
The following JIRA issue may be the same thing:
http://opensource.atlassian.com/projects/hibernate/browse/ANN-298
The following messages on the Hib forum demonstrate other interest in this issue:
http://forum.hibernate.org/viewtopic.php?t=949913
http://forum.hibernate.org/viewtopic.php?t=956778
http://forum.hibernate.org/viewtopic.php?t=962471
java.lang.ClassCastException: com.nomadsoft.cortex.domain.country.basic.BasicCountry
at org.hibernate.type.StringType.toString(StringType.java:44)
at org.hibernate.type.NullableType.toLoggableString(NullableType.java:168)
at org.hibernate.pretty.MessageHelper.collectionInfoString(MessageHelper.java:284)
at org.hibernate.loader.Loader.readCollectionElement(Loader.java:972)
at org.hibernate.loader.Loader.readCollectionElements(Loader.java:635)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
at org.hibernate.loader.Loader.doQuery(Loader.java:689)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:177)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:792)
at org.springframework.orm.hibernate3.HibernateTemplate$1.doInHibernate(HibernateTemplate.java:452)
at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:366)
at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:446)
at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:440)
at com.nomadsoft.cortex.infrastructure.hibernate.HibernateCountryRepository.getById(HibernateCountryRepository.java:26)
at com.nomadsoft.cortex.domain.country.basic.BasicCountryService.getCountry(BasicCountryService.java:34)
etc etc
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-4550) query cache: Attention with configuring Update Timestamps Cache region: expired entries cause wrong result sets!
by Guenther Demetz (JIRA)
query cache: Attention with configuring Update Timestamps Cache region: expired entries cause wrong result sets!
----------------------------------------------------------------------------------------------------------------
Key: HHH-4550
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4550
Project: Hibernate Core
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.2
Environment: 3.3.2 GA
Reporter: Guenther Demetz
Priority: Trivial
Attachments: TestCaseQuryCache.jar
When using hibernate's query cache (hibernate.cache.use_query_cache),
then it's of fundamental importance to configure the Update Timestamps cache region in
a way that his entries survive longer than the cached result sets in the Query cache region.
Otherwise queries could return wrong (obsolete) result sets (See attached testcase).
This is because the current UpdateTimestampsCache#isUpToDate implementation considers a result-set also as up-to-date,
if there are no update-timestamps cached for the interested spaces (tables) at all.
It if therefore important to notice that:
1- The Update-Timestamps-Cache-Region elements max-size should be configured higher than the number of tables you have
on the db-schema, in manner that he can remember/hold the last update-timestamp for each table.
2- If you use any other eviction policy in the Update-Timestamps-Cache-Region, then you must assure
that cached result sets in the Query-cache-region are evicted before relevant update-timestamps are going to be evicted.
This fact should be clearly documented somewhere.
Thanks
G.D.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3892) Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[]
by Gail Badner (JIRA)
Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[]
---------------------------------------------------------------------------------------------------------------
Key: HHH-3892
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3892
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Gail Badner
Assignee: Gail Badner
Fix For: 3.2.x, 3.3.x, 3.5
Property types will be provided to enable an application to process data for a java.sql.Types.LONGVARCHAR or java.sql.Types.CLOB column as a Java String. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java string.
text - property type to map java.sql.Types.LONGVARCHAR column data as a Java String (via org.hibernate.type.TextType);
(NOTE: currently, org.hibernate.type.TextType incorrectly maps "text" to java.sql.Types.CLOB; this will be fixed by this issue and updated in database dialects)
materialized_clob - property type to map java.sql.Types.CLOB column data as a Java String (via org.hibernate.type.MaterializedClobType);
In addition, new property types will be provided to enable an application to process data for a java.sql.Types.LONGVARBINARY or java.sql.Types.BLOB column as Java byte[]. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java byte[].
image - property type to map java.sql.Types.LONGVARBINARY column data as byte[] (via org.hibernate.type.ImageType);
materialized_blob - property type to map java.sql.Types.BLOB column data as byte[] (via org.hibernate.type.MaterializedBlobType);
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-4555) Support use of Envers with Auto-commit mode.
by Kevin Schmidt (JIRA)
Support use of Envers with Auto-commit mode.
--------------------------------------------
Key: HHH-4555
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4555
Project: Hibernate Core
Issue Type: New Feature
Components: envers
Affects Versions: 3.5.0-Beta-2
Environment: Hibernate 3.5.0-Beta-2
Reporter: Kevin Schmidt
Currently Envers is designed so that it synchronizes with the currently running transaction in order to know when to commit the inserts into the Audit Tables. This is an effective strategy for ensuring that the audit information is only saved to the database if the Transactional Unit of Work which caused the audit data to be created is committed.
This design creates a limitation on Envers such that it cannot persist audit information unless there is an active transaction. This effectively disables auditing for anyone modifying data using Hibernate outside of a Hibernate Transaction. Specifically, if you are using Autocommit = True and manually flushing the Hibernate Session then you cannot have any of your data audited using Envers.
I am not that well versed with the design of Envers but was hoping this situation could be detected and avoided. Maybe the audit information could be synchronized on the flush event rather than when a transaction is committed to the database.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3383) QueryKey is storing references to entities instead of identifiers
by Manuel Dominguez Sarmiento (JIRA)
QueryKey is storing references to entities instead of identifiers
-----------------------------------------------------------------
Key: HHH-3383
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383
Project: Hibernate3
Issue Type: Improvement
Components: caching (L2)
Affects Versions: 3.3.0.CR1
Environment: ehcache 1.5.0b2
Reporter: Manuel Dominguez Sarmiento
Context: query caching
Hibernate is storing full entity references when building QueryKeys and the query has restrictions which reference entities. This happens either with Criteria or HQL queries.
Although this is not incorrect, when the referenced entities reference in turn "heavy" object graphs, this causes a very significant memory usage increase, since references to detached entities will remain in the cache. This is even more evident when using disk persistence with ehcache, since the full object graphs are serialized to disk.
This could be easily improved (correct me if I'm wrong) by storing ONLY entity identifiers in the QueryKey instead of full entities, since all the query really needs is the identifier property. The memory usage would decrease dramatically.
So far the workaround we've found is explicitly using restrictions that reference identifiers instead of properties in HQL queries, however this is not particularly elegant, and still leaves open the issue with Criteria queries. The same cannot be done without criteria.createCriteria() which generates an unnecessary join in most cases.
--
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, 5 months