12:46 p.m.
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
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.
-
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
5:19 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater commented on HHH-3910:
-------------------------------------
I'd be interesting in seeing the direction this takes. We already keep track of the
properties that were changed in a map so that we can execute dynamic updates. A few years
back I took a run at looking to use this map to find the dirty objects instead of having
to do a deep equals on the entity but there were 1 or 2 cases where it fell down (I've
been meaning to go back and look). Flush perfomance for us has always been a hot topic as
our object model is very deep and we end up having a bunch of things kicking around.
Anything that could be done to speed this up would be a Godsend.
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
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.
-
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
6:37 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater commented on HHH-3910:
-------------------------------------
I've been thinking about this overnight and have come up with something I am at least
going to try.
Rather than have an interface that an entity has to implement I was thinking that it might
be better served in the Persister layer. There is already transient functionality in
there so dirty isn't that far off I don't think.
Something like
public Boolean isDirtyCheckRequired(Object entity) throws HibernateException {
The implementation could be to check a flag, status or whatever.
Then I think the place to check it is in
EntityEntry
public boolean requiresDirtyCheck(Object entity) {
boolean isMutableInstance =
status != Status.READ_ONLY &&
persister.isMutable();
return isMutableInstance && getPersister().isDirtyCheckRequired(entity)
&& (
getPersister().hasMutableProperties() ||
!FieldInterceptionHelper.isInstrumented( entity ) ||
FieldInterceptionHelper.extractFieldInterceptor( entity).isDirty()
);
}
That way it looks like it would bypass the findDirty, findModified, getSnapshot
functionality but retain the ability to still delete the entities, etc. I'll have to
see what it does to the cascade bits but I think in my case being able to skip all of the
supporting data for an insert or update might buy me quite a gain.
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
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.
-
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
11:26 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Ovidio Mallo commented on HHH-3910:
-----------------------------------
Shawn, thanks for the feedback!
Indeed, it is in EntityEntry#requiresDirtyCheck(Object entity) where the current dirty
check using bytecode instrumentation is performed. So adding support for a custom dirty
checking at the place where this method is called (in DefaultFlushEntityEventListener) as
you are suggesting would already give the desired performance gain. If following this
approach, I think it would also be important for clients to have a clear hook where they
can clear their custom dirty flag (after flush), ideally also inside the
DefaultFlushEntityEventListener class to keep it close to the actual dirty checking code.
BTW, I've also posted another JIRA issue regarding the performance of the
FieldInterceptionHandler class which is important when using bytecode instrumentation.
I've attached a patch to that issue which significantly improves the performance of
the functionality provided by that class which in turn has a positive impact on the flush
performance, especially if bytecode instrumentation is used for dirty checking during
flush. Using my patch, flushing a large number of non-dirty objects becomes about 6-7
times faster when using bytecode instrumentation (see the measurements presented there)
for dirty checking, so I would expect at least the same performance gain with the approach
you are suggesting with the additional advantage that you don't need any bytecode
instrumentation. For the patch and some performance measurements, please see the following
JIRA issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3909
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
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.
-
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:38 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater updated HHH-3910:
--------------------------------
Attachment: DirtyCheckFailedAttempt.patch
Here is a patch with what I thought might work but it seems to be a little more complex
that what it appears. It looks like if the might be dirty is false it can fail to get the
correct state in the getValues() call, the loadedValue is actually different than the
current state.
Later when it tries to process the collections it comes off the rails complaining about
dereferenced collections, I'm not 100% sure where the disconnect is. I thought it
might have been the order in which the instrumentation calls are processed but I moved it
to the end as well with the same result.
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.
-
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
11:22 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Ovidio Mallo commented on HHH-3910:
-----------------------------------
Does the problem of having wrong values in EntityEntry#getLoadedState() already occur if
using bytecode instrumentation for dirty checking? Do you maybe have a testcase where I
could reproduce this?
BTW, I'm not sure whether the current check in the patch as of whether a dirty check
is required or not is correct. Right now, it reads as follows:
return isMutableInstance && (
getPersister().hasMutableProperties() &&
getPersister().isDirtyCheckRequired(entity)||
!FieldInterceptionHelper.isInstrumented( entity ) ||
FieldInterceptionHelper.extractFieldInterceptor( entity).isDirty()
);
In particular, I'm not sure about the following two points:
* If getPersister().hasMutableProperties() == false and
getPersister().isDirtyCheckRequired(entity) == true, dirty checking may be skipped even
though it should probably be performed.
* If a mutable entity is not instrumented, the expression seems to always return true,
thus leading to a dirty check even if getPersister().isDirtyCheckRequired(entity) ==
false.
I would rather have expected something like the following (I've split things up to
keep them simpler):
if (!isMutableInstance) {
return false;
}
if (getPersister().hasMutableProperties()) {
return true;
}
// Do custom dirty checking before doing dirty checking through bytecode instrumentation.
if (!getPersister().isDirtyCheckRequired(entity)) {
return false;
}
return !FieldInterceptionHelper.isInstrumented( entity ) ||
FieldInterceptionHelper.extractFieldInterceptor( entity).isDirty();
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.
-
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
3:42 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater commented on HHH-3910:
-------------------------------------
Yeah, I think i might have screwed that up when I put it back to what I initially tried.
I originally had what I posted before I did the patch
return isMutableInstance && getPersister().isDirtyCheckRequired(entity) &&
(
getPersister().hasMutableProperties() ||
!FieldInterceptionHelper.isInstrumented( entity ) ||
FieldInterceptionHelper.extractFieldInterceptor( entity).isDirty()
);
My thoughts were that if it wasn't dirty from me tagging it as such then I don't
want to continue to even check.
The way you have it, it's going to return true any time you have a mutable property
and that's essentially always going to return true for any entity with updatable
properties so it's not really going to buy you anything except bypass the
instrumentation call but I'm not sure that is even valid as it can be dirty as well.
I don't have a standalone test case right now but I can maybe do one up in a couple of
days, I'm not even sure I understand what's going on since the code that was
failing on my side is wrapped up in some rather convoluted logic.
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.
-
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
10:18 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Ovidio Mallo commented on HHH-3910:
-----------------------------------
I thought that EntityPersister#hasMutableProperties() was only returning true for more
"special" things like components and the like but in any case it's indeed
better to check for custom dirty checking before checking for mutable properties so I
would say that your new expression is the right one.
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.
-
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
9:20 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
How is this different from what is offered by {{org.hibernate.Interceptor#findDirty}} ?
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
9:24 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
Well I guess in the case of {{org.hibernate.Interceptor#findDirty}} it is still a
significant performance improvement
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
11:35 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater commented on HHH-3910:
-------------------------------------
Steve, you have impeccable timing :D
I'm about to go back and see if I can squeeze out some extra performance during
flushing. I'm not convinced I can't get it done by just providing a custom impl
in my persister but the dirty check didn't seem to be as big a factor as I had thought
in the whole flushing scheme (I haven't quite fully profiled the time yet but the
dirty check was about 20% overall from what I had found in my testing).
With that aside, here's our scenario. We're already keeping track of modified
properties (for our auditing) so we figured we should be able to use that for our dirty
check. Our properties are tracked in a map via their names with their original values.
So ultimately rather than having to check equality on n number of properties using
reflection the thought is that I can bypass that altogether for 'clean' entities
if their map is empty. I had a run at this a few years back and there was one case where
an entity was getting updated and setting a field directly bypassing our audit and
slipping through the cracks.
We've got some monstrous processes and sometimes get hammered with flush times so
we're looking at squeezing out whatever we can (as well as trying to be smart with
batches and clearing the sessions, etc). I had just seen Ovidio struggling with the same
thing a few years back and was hopping on the bandwagon to see if we could eke anything
out.
I may very well roll our environment up to 4 to see if perf is any better, I think I saw
some initiatives to optimize cascade flushing but I may as well tune on what we'll
eventually be running on. Just not enough hours in a day :D
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
11:41 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
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
11:43 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
Shawn, 4.0 does offer better performance versus 3.x in our testing and testing done by a
team at JBoss
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
11:49 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) Add support for custom dirty checking during flush
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
See also HHH-6735 as it affects some of the same code...
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
Labels: performance
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
11:52 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole updated HHH-3910:
--------------------------------
Summary: custom dirty flag tracking (was: Add support for custom dirty checking
during flush)
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
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
11:54 p.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole updated HHH-3910:
--------------------------------
Fix Version/s: 4.1.0
Lets see if we can get this into 4.1
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
12:15 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater commented on HHH-3910:
-------------------------------------
Steve, glad to hear about the better performance. I'll have to search to see if the
gains were documented anywhere, that might make my request to get some time to roll up to
4 higher priority.
On the skipDirtyCheck bit, I agree, I'm not a huge fan of having to implement an
interface which is why I went down the persister path (we're already tapping into a
custom persister for auditing and some filter massaging and it's a bit of a decent
fit.)
I think the place where I did run into trouble is in the case where a many to one was
deleted and Hibernate circled back and tried to update the property to null. IIRC, that
was the case that was slipping through the cracks for me, it didn't update my entity
directly (which didn't update my map) but the loaded/current arrays were different
lengths.
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
3:24 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
Those arrays should never have different lengths. An element of an array being null does
not affect its length...
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
4:13 a.m.
New subject: [Hibernate-JIRA] Issue Comment Edited: (HHH-3910) custom dirty flag tracking
[
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
4:32 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
Just to document my thoughts on this for later...
Also might be a good idea to bundle both the {{FieldInterceptor}} and this new (proposed)
{{EntityDirtyFlagChecker}} handling behind a single {{SessionFactory}} delegate. That
would remove the need for the null checking in client code and makes for better
encapsulation in general. Something like:
{code:title=DirtyFlagManager.java|borderStyle=solid}
public class DirtyFlagManager {
private final SessionFactoryImplementor sessionFactory;
private final EntityDirtyFlagChecker customDirtyFlagChecker;
public boolean isUnequivocallyDirty() {
if ( getPersister().getFactory()
.getServiceRegistry()
.getService( InstrumentationService.class )
.isInstrumented( entity ) ) {
return ! FieldInterceptionHelper.extractFieldInterceptor( entity ).isDirty();
}
if ( customDirtyFlagChecker != null ) {
return customDirtyFlagChecker.canSkipDirtyChecking( entity );
}
return false;
}
public void makeDirty(Object entity) {
...
}
public void resetDirty(Object entity) {
...
}
}
{code}
Obviously there needs to be some unification of method names here, but in general I think
this is a good thing...
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
1:12 a.m.
New subject: [Hibernate-JIRA] Updated: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole updated HHH-3910:
--------------------------------
Assignee: Steve Ebersole
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Assignee: Steve Ebersole
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
5:11 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
Not sure exactly where to fit this in the existing documentation. It does not see to fit
nicely anywere. Maybe y'all have some suggestions?
In the meatime, I'll quickly document its use here and write a blog entry tomorrow.
The contract here is named {{org.hibernate.CustomEntityDirtinessStrategy}}. It defines
only 3 methods:
{code:title=CustomEntityDirtinessStrategy.java|borderStyle=solid}
public interface CustomEntityDirtinessStrategy {
/**
* Is this strategy capable of telling whether the given entity is dirty? A return of
{@code true} means that
* {@link #isDirty} will be called next as the definitive means to determine whether the
entity is dirty.
*
* @param entity The entity to be check.
* @param session The session from which this check originates.
*
* @return {@code true} indicates the dirty check can be done; {@code false} indicates it
cannot.
*/
public boolean canDirtyCheck(Object entity, Session session);
/**
* The callback used by Hibernate to determine if the given entity is dirty. Only called
if the previous
* {@link #canDirtyCheck} returned {@code true}
*
* @param entity The entity to check.
* @param session The session from which this check originates.
*
* @return {@code true} indicates the entity is dirty; {@link false} indicates the entity
is not dirty.
*/
public boolean isDirty(Object entity, Session session);
/**
* Callback used by Hibernate to signal that the entity dirty flag should be cleared.
Generally this
* happens after previous dirty changes were written to the database.
*
* @param entity The entity to reset
* @param session The session from which this call originates.
*/
public void resetDirty(Object entity, Session session);
{code}
This is what your code would implement. You specify this using the
{{hibernate.entity_dirtiness_strategy}} setting
(org.hibernate.cfg.AvailableSettings#CUSTOM_ENTITY_DIRTINESS_STRATEGY}}).
That's basically it.
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Assignee: Steve Ebersole
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
5:52 a.m.
New subject: [Hibernate-JIRA] Resolved: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole resolved HHH-3910.
---------------------------------
Resolution: Fixed
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Assignee: Steve Ebersole
Labels: performance
Fix For: 4.1.0
Attachments: DirtyCheckFailedAttempt.patch
Time Spent: 4h 26m
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
4 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Shawn Clowater commented on HHH-3910:
-------------------------------------
Steve, I can't wait to give this a spin, just need to convince someone to allocate
some time to get to 4 first.
Taking a peek at the changes, the resetDirty call isn't buried in the core? i.e.
we'll have the flexibility to call it where it makes the most sense?
I'm not sure of the case where I'd have 2 pieces of logic called for isDirty and
canDirtyCheck but I need to think through how I'll tie into it. I think we'll
find in our cases quite a bit of improvement if we can bypass the check on our large
entities.
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Assignee: Steve Ebersole
Labels: performance
Fix For: 4.1.0
Attachments: DirtyCheckFailedAttempt.patch
Time Spent: 4h 26m
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
5:24 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3910) custom dirty flag tracking
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910?page=c...
]
Steve Ebersole commented on HHH-3910:
-------------------------------------
{quote}
Taking a peek at the changes, the resetDirty call isn't buried in the core? i.e.
we'll have the flexibility to call it where it makes the most sense?
{quote}
Not really sure what you are asking here. {{resetDirty}} is called after changes are
written to the db. You have to keep in mind that with this approach your code is now the
keeper of this dirty flag. Hibernate can't reset it because you control it. So you
can reset it whenever you see fit. This is just a hook for Hibernate to tell you that its
probably a good time to reset it because those changes have been written to the db.
{quote}
I'm not sure of the case where I'd have 2 pieces of logic called for isDirty and
canDirtyCheck but I need to think through how I'll tie into it. I think we'll find
in our cases quite a bit of improvement if we can bypass the check on our large entities.
{quote}
Well I think you have to remember that this is plugged in at the {{SessionFactory}} level.
You may not be controlling a dirty flag for each and every entity. Hence the
{{canDirtyCheck}}.
Right now, {{isDirty}} only has a perf benefit if it returns false which will circumvent
the "dirty checking". Something to keep in mind that "dirty checking"
also encompasses figuring out which attributes changed. If {{isDirty}} returns true, we
still need to do that work in order to determine which attributes changed.
Something extra I have contemplated here (still not sure) is to expand this
{{CustomEntityDirtinessStrategy}} concept a little to also allow it to report which
attributes are changed, something akin to {{org.hibernate.Interceptor#findDirty}}.
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Assignee: Steve Ebersole
Labels: performance
Fix For: 4.1.0
Attachments: DirtyCheckFailedAttempt.patch
Time Spent: 4h 26m
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
5:22 a.m.
New subject: [Hibernate-JIRA] Closed: (HHH-3910) custom dirty flag tracking
[
https://hibernate.onjira.com/browse/HHH-3910?page=com.atlassian.jira.plug...
]
Steve Ebersole closed HHH-3910.
-------------------------------
Closing for 4.1 release
custom dirty flag tracking
--------------------------
Key: HHH-3910
URL: https://hibernate.onjira.com/browse/HHH-3910
Project: Hibernate ORM
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Ovidio Mallo
Assignee: Steve Ebersole
Labels: performance
Fix For: 4.1.0
Attachments: DirtyCheckFailedAttempt.patch
Time Spent: 4h 34m
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
4526
days inactive
5531
days old
hibernate-issues@lists.jboss.org
25 comments
3 participants
participants (3)
-
Ovidio Mallo (JIRA) -
Shawn Clowater (JIRA)
-
Steve Ebersole (JIRA)