[hibernate-dev] Re: HSEARCH-178
emmanuel at hibernate.org
Tue Apr 14 04:44:59 EDT 2009
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,
> 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
> After this I removed the delegation moving the code to the
> 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
> 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
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
> 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
> 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
More information about the hibernate-dev