9:13 p.m.
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole edited comment on HHH-3910 at 12/27/11 9:12 PM:
---------------------------------------------------------------
I am not a fan of an interface that entities must implement *in terms of a Hibernate
interface*. However, what I could see is something like the following:
{code:title=EntityDirtyFlagChecker.java|borderStyle=solid}
public interface EntityDirtyFlagChecker {
public boolean canSkipDirtyChecking(Object entity);
public void makeDirty(Object entity);
public void resetDirty(Object entity);
}
{code}
Allow an instance to be registered with the {{SessionFactory}}. This would then be used
in parallel, so to speak, with the enhanced/instrumented variant. Something like:
{code:title=EntityEntry.java|borderStyle=solid}
public boolean requiresDirtyCheck(Object entity) {
return isModifiableEntity()
&& getPersister().hasMutableProperties()
&& ! shouldSkipDirtyChecking( object );
}
private boolean shouldSkipDirtyChecking(Object entity) {
if ( getPersister().getFactory().getServiceRegistry().getService(
InstrumentationService.class ).isInstrumented(entity) ) {
return ! FieldInterceptionHelper.extractFieldInterceptor( entity ).isDirty();
}
final EntityDirtyFlagChecker dirtyFlagChecker = ...;
if ( dirtyFlagChecker != null ) {
return dirtyFlagChecker.canSkipDirtyChecking( entity );
}
return false;
}
{code}
And of course, appropriate calls to makeDirty/resetDirty
WDYT?
was (Author: steve):
I am not a fan of an interface that entities must implement *in terms of a Hibernate
interface*. However, what I could see is something like the following:
{code:title=NonEnhancedEntityDirtyFlagManager.java|borderStyle=solid}
public interface NonEnhancedDirtyFlagChecker {
public boolean canSkipDirtyChecking(Object entity);
public void makeDirty(Object entity);
public void resetDirty(Object entity);
}
{code}
Allow an instance to be registered with the {{SessionFactory}}. This would then be used
in parallel, so to speak, with the enhanced/instrumented variant. Something like:
{code:title=EntityEntry.java|borderStyle=solid}
public boolean requiresDirtyCheck(Object entity) {
return isModifiableEntity()
&& getPersister().hasMutableProperties()
&& ! shouldSkipDirtyChecking( object );
}
private boolean shouldSkipDirtyChecking(Object entity) {
if ( getPersister().getFactory().getServiceRegistry().getService(
InstrumentationService.class ).isInstrumented(entity) ) {
return ! FieldInterceptionHelper.extractFieldInterceptor( entity ).isDirty();
}
final NonEnhancedDirtyFlagChecker customDirtyFlagChecker = ...;
if ( customDirtyFlagChecker != null ) {
return customDirtyFlagChecker.canSkipDirtyChecking( entity );
}
return false;
}
{code}
And of course, appropriate calls to makeDirty/resetDirty
WDYT?
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Labels: performance
Fix For: 4.1.0
Attachments: DirtyCheckFailedAttempt.patch
Currently, Hibernate supports a special dirty checking on instrumented entities
in order to improve the flush performance. IMO, this optimization can often be
rather significant. However, the drawback is that you have to use bytecode
instrumentation in order to take advantage of this performance improvement which
might not be an option in some projects.
Therefore, I wanted to propose to extend the current dirty checking during flush
in such a way that the dirtyness information can also be directly provided by
clients. Thereby, I could think of two possible approaches to do this:
1. Introduce an interface which client entities might implement in case they
have some notion of dirtyness. The interface could look something like:
public interface DirtyAwareEntity {
boolean getMightBeDirty();
void setMightBeDirty(boolean mightBeDirty);
}
Using such an interface, Hibernate could easily check whether an entity might
be dirty during flush and it could also reset the dirty flag after flush just
as is currently done for instrumented classes. So this approach would probably
be rather easy to implement and very convenient for clients since they would
only have to implement that interface on the appropriate entities and set the
dirty flag when the entity is actually modified.
2. Add some hooks on event listeners and/or on the Interceptor for querying whether
an entity is dirty and for resetting the dirty flag. E.g. one could add the
following hook method to the DefaultFlushEntityEventListener class:
protected boolean requiresDirtyCheck(FlushEntityEvent event);
By default, this method would call EntityEntry#requiresDirtyCheck(Object entity)
as is done right now.
Resetting the dirty flag could maybe be done in Interceptor#postFlush() or some
dedicated method could be provided.
BTW, I know that currently there already is the Interceptor#findDirty() method which
already allows for some custom dirty checking but the problem from a performance
point of view is that this method requires the entity's property values as parameter
which are retrieved in DefaultFlushEntityEventListener#getValues() which is the most
expensive method during flush. This drawback of the findDirty() method has often been
noticed in comments on the news groups.
I personally think it would be nice if something could be done to improve the
performance of flushing in Hibernate since from what I read on the news groups and
the like, flushing still seems to often lead to performance problems in practice,
especially in larger projects where it is often not easy to avoid flushes or to
keep the numer of entities in the session cache small. In fact, we are having quite
some trouble with that in our project and having some custom dirty checking like the
one I'm proposing here would greatly help in our project and in other projects as
well, I guess.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira