[hibernate-dev] Re: HSEARCH-178

[Emmanuel Bernard]

Read inline

On  Apr 13, 2009, at 17:22, Sanne Grinovero wrote:

> After our chat about the topic I thought that I only needed some  
> minor changes,
> was quite wrong.
>
> I moved the flush listener to the usual FullTextIndexEventListener,  
> using
> delegation at first as we had agreed. This got me into troubles with
> the Serialization test of the FullTextEntityManager, I had to adapt
> EventSourceTransactionContext changing a field to transient and
> having the code manage the case in which the values are lost by  
> deserialization.
> After this I removed the delegation moving the code to the
> FullTextIndexEventListener
> which resulted in simpler code.
>
> You made me think about what was happening in case of an error during
> the flush processing in the default listener, so I've replaced the Map
> with a combination
> of non-static ThreadLocal with a weak reference to the flushing  
> Session,
> which is checked for == identity to make sure the synch is relevant to
> the same session,
> in case of a previously not cleaned-up flush by the same Thread (as in
> a Map, but I only need
> the last stored value for the current session, and only for the same  
> thread).

I think I don't like the ThreadLocal approach. What is your reasoning  
for using a thread local variable? What would make it less compelling  
if we were not using a TL?

>
> I avoided "static" for this ThreadLocal to have it cleanup at
> SessionFactory close,

makes sense. The map should be scoped to the event listener.

>
> and needed to be both "final" and "transient" for respectively
> concurrency and serializability.
> I've had to add a customized readObject to recreate the ThreadLocal  
> after
> a deserialization, using Reflection to set the final field.

That is weird. I thought readObject had the same rights than  
constructors wrt to final assignment.

>
> A bit messy, I'm not very satisfied, but it's working fine.
>
> I'm committing it to trunk, but would be glad if someone
> could get an idea to make it a bit cleaner/simpler.
> Also I'll wait for a "go" before merging it to 3.1 branch
>
> Sanne
>
>
> 2009/4/8 Emmanuel Bernard <emmanuel at hibernate.org>:
>> Just port it also to trunk and we will see if it's stable.
>> We will probably carve a 3.1.1 soon and a 3.1.2 if something bad is
>> happening I guess
>> On  Apr 8, 2009, at 11:48, Emmanuel Bernard wrote:
>>
>>> yes ideally trunk is better suited for experiments
>>>