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

Fri Mar 13 18:18:32 EDT 2009

hello

On  Mar 13, 2009, at 17:54, Sanne Grinovero wrote:

> Hi,
> about this issue (HSEARCH-178) I've implemented a patch following your
> directions and
> your idea is working very well, but I'm having some trouble about the

Cool

>
> configuration
> of listeners.
>
> An additional flush listener is needed; I've patched the
> autoregistration but people
> not using annotations will have to specify both
> DefaultFlushEventListener and the
> new IndexWorkFlushEventListener in their configuration.

yes. Actually you might have to listen to both flush and auto-flush.

>
> I've been able to specify the pair of listeners using programmatic  
> configuration
> and using hibernate.cfg.xml but is this also possible with  
> hibernate.properties

no

>
> and persistence.xml ?

yes
add the property
hibernate.ejb.event.flush =  
org.hibernate.ejb.event.EJB3FlushEventListener, o.h.s.e.  
IndexWorkFlushEventListener

http://hibernate.org/hib_docs/entitymanager/reference/en/html_single/#d0e500

>
> I couldn't find any docs or examples to register two event listeners  
> for the
> same event in JPA, I'm wondering if instead of adding a listener I  
> should
> not extend or wrap the DefaultFlushEventListener so to have only one
> listener?

I don't like the idea, we introduce arrays of event listeners for that  
purpose.

>
>
> Would this work for JPA also or should I have to extend the
> EJB3FlushEventListener
> instead? I see it's different.

Yes you would need a different one or different two because of  
(EJB3AutoFlushEventListener). so not a good idea :)

>
>
> In case the JPA listener should be different than the hibernate
> version, how can I
> detect the listener I should register in the EventListenerRegister
> autoregistration
> routine?

Another good reason why it's a bad idea.

>
>
> To be backwards-compatible with our own configuration I've slightly  
> modified
> the patch to work as the old way (loading collections in flush) when
> the listener
> is not found; a warning is logged saying the listener should be  
> registered.

I don't quite understand why, the new EventListenerREgister will be  
bundled with the IndexWork Listener always right? What backward  
compatible mode do you have?
BTW, you should put a warning in the log when this event listener is  
used.
"Applying change to the full-text index before transaction completion.  
Please use a Hibernate aware transaction (eg  
org.hibernate.Transaction, javax.persistence.EntityTransaction, JTA  
transaction with the proper TransactionFactory setting)"

>
>
> hope we can fix this,
> Sanne
>
>
> 2009/3/7 Emmanuel Bernard <emmanuel at hibernate.org>:
>> We discussed the issue with Sanne and for Hibernate Search we have a
>> workaround solution that does not penalize Hibernate Core. This  
>> solution can
>> be applied by everybody but it's not the easiest thing on Earth.
>>
>> The idea is to queue as you said but inside custom event listeners.  
>> In our
>> case some Post* event listeners. This queue is "flushed" in a
>> FlushEventListener. This new flush event listener must be  
>> registered *after*
>> the default FlushEventListener.
>>
>> All this does not require Hibernate Core change and requires  
>> minimal change
>> to the Hibernate Search code and architecture.
>>
>> On  Mar 6, 2009, at 10:15, Steve Ebersole wrote:
>>
>>> 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/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
>>> steve at hibernate.org
>>>
>>> Principal Software Engineer
>>> JBoss, a division of Red Hat
>>> http://jboss.com
>>> http://redhat.com
>>> steve.ebersole at jboss.com
>>> steve.ebersole at 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
>>>>> steve at hibernate.org
>>>>>
>>>>> Principal Software Engineer
>>>>> JBoss, a division of Red Hat
>>>>> http://jboss.com
>>>>> http://redhat.com
>>>>> steve.ebersole at jboss.com
>>>>> steve.ebersole at 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 at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>