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(a)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
>>