[hibernate-dev] Re: HSEARCH-178

[Sanne Grinovero]

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 avoided "static" for this ThreadLocal to have it cleanup at
SessionFactory close,
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.
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
>>