Not sure what you mean by your "In theory it should not"... The very
nature of @PostUpdate is that it is going to be getting called during a
flush cycle...
wrt "is it possible to move the post* event after the flush?"...
There are really 2 answers.
1) According to the JPA spec, can we do this? The quote from the
current spec says:
The PreUpdate and PostUpdate callbacks occur before and after the
database update operations to
entity data respectively. These database operations may occur at the
time the entity state is updated or
they may occur at the time state is flushed to the database (which may
be at the end of the transaction).
I don't really see anything there that discusses the time-relationship
between the SQL UPDATE execution and the @PostUpdate callback other than
the fact that (obviously) @PostUpdate callback should come after the SQL
UPDATE is issued; but it does not seem to limit *how long after*. So I
think this is OK from the perspective of the spec.
2) Can Hibernate be changed to do this? Well AnythingIsPossible in
programming, so I guess the question really is *should* we change
Hibernate to do this. My main concern with this change is the extra
queueing it would require and the corollary memory requirements. What
happens right now is that those callbacks are executed during the action
(org.hibernate.action.Executable) execution. Flush puts them into a
queue of actions (org.hibernate.engine.ActionQueue), from which they are
removed as they are executed. We decided to put the post callbacks in
the actions themselves for assurance-of-execution as well as
encapsulation purposes, which I think are both still worthwhile. What I
could see as a potential solution would be to do something like we do
for Actions which have "after transaction" tasks to perform:
http://fisheye.jboss.org/browse/Hibernate/core/trunk/core/src/main/java/org/hibernate/engine/ActionQueue.java?r=16091#l271
The "executions" list here is a queue of actions which we need to keep
around for later. I can see something like that in conjunction with a
method on ActionQueue to process that internal 'callbacks' queue after
the entire flush is complete. Note that this does not address
@PreUpdate.
We can investigate that though and see what we are talking about in
specific.
-
Steve Ebersole
Project Lead
http://hibernate.org
st...@hibernate.org
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
steve.ebers...@jboss.com
steve.ebers...@redhat.com
On Fri, 2009-03-06 at 09:07 -0500, Emmanuel Bernard wrote:
> Ahhh
> In theory it should not as Hibernate Search reads data in the
> beforeCompletion phase.
> Unless people do not apply changes in a transaction in which case we
> need to execute the read in the post* event.
>
> We will check whether or not people use surrounding transactions
> (Hibernate aware Tx either through JTA or via the direct Hibernate
> Transaction API).
> Alternatively, is it possible to move the post* event after the flush?
> Or create noew events for that? That would solve everybody's issue.
>
> Emmanuel
>
> On Mar 5, 2009, at 22:54, Steve Ebersole wrote:
>
> > Is this somehow different than the "attempt to load stuff into the PC
> > during flush" scenarios I see in any of these related issues?
> >
> > -
> >
> > Steve Ebersole
> > Project Lead
> > http://hibernate.org
> > st...@hibernate.org
> >
> > Principal Software Engineer
> > JBoss, a division of Red Hat
> > http://jboss.com
> > http://redhat.com
> > steve.ebers...@jboss.com
> > steve.ebers...@redhat.com
> >
> >
> > On Thu, 2009-03-05 at 19:14 -0500, Emmanuel Bernard wrote:
> >> http://opensource.atlassian.com/projects/hibernate/browse/HHH-3225
> >>
> >> Steve, any chance you could look at this one, it seems to hit HSearch
> >> users on a regular basis.
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
