Re: [hibernate-dev] HHH-3225 is hitting Hibernate Search

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: <quote> 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). </quote> 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/o... 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 steve(a)hibernate.org Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com steve.ebersole(a)jboss.com steve.ebersole(a)redhat.com On Fri, 2009-03-06 at 09:07 -0500, Emmanuel Bernard wrote: