[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush

[Steve Ebersole (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44737#comment-44737 ] 

Steve Ebersole commented on HHH-3910:
-------------------------------------

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?

> Add support for custom dirty checking during flush
> --------------------------------------------------
>
>                 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
>         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