Thanks for the feedback.
Yes HibernateMassIndexed (not Impl suffix) would be a better name.
I am thinking that we could use something like what I have done in
bean validation to have Hibernate specific MassIndexer properties type-
safely exposed as a subinterface of the public MassIndexer.
Maybe it's better to mark MAssIndexer as potentially still evolving
and get feedback on the API first.
Emmanuel
On 25 oct. 09, at 19:57, Sanne Grinovero wrote:
> Hi Emmanuel,
>
> I guess some classes would result similar in an Infinispan based mass
> indexer, bit this is coupled to which are the efficient strategies to
> get a continuous flow of Documents.
> It mostly depends on how you're going to store structured entities in
> Infinispan? The whole graph needed by a DocumentBuilder is found on
> the same key? (i.e. no lazy loading?)
> Sure a non-tuned implementation would not be hard, but we might find
> out that to make it fast it needs a larger set of changes maybe up to
> the API.
>
> Some classes would be reused with minimal changes, as whatever the
> source is I'd still recommend to use the multiple-parallel-queues
> idea, so at least these:
>
> ProducerConsumerQueue,
> MassIndexerProgressMonitor,
> Executors
> even the coordinator BatchCoordinator could work unchanged;
>
> All classes in org.hibernate.search.backend.impl.batchlucene would
> also work unchanged.
>
> I can't really abstract-away Hibernate from the MassIndexerImpl and
> the 2 Runnable types it spawns, the strategies it uses are tailored
> for Hibernate: exploit caches, fight delay on lazyloading,
> detach-reattach to session at thread switches, pool the Session(s). I
> guess you could rename it to HibernateMassIndexerImpl? Another
> implementation could easily combine the other classes as common
> utilities but I'd bet the main strategy would be different.
>
> you say "aside from the MassIndexer interface", note I'm exposing
> cacheMode(org.hibernate.CacheMode cacheMode) on the interface.
> I've seen consistent performance differences in enabling/disabling the
> caches, in some models clearly faster enabling it, in others disabling
> it, so I need some way to set this.
> We could change that to a boolean, as only IGNORE/NOT_IGNORE the
> caches are interesting options. Other implementations could then
> ignore this setting if caching doesn't make sense to them.
>
> After having made the API "hibernate free" we can change the factory
> to return a different impl whatever the storage engine is. (we call it
> "storage engine" ?)
>
> Sanne
>
>
> 2009/10/25 Emmanuel Bernard :
>> Hey Sanne,
>> MassIndexerImpl is 100% dependent of Hibernate Core (you pass a
>> SessionFactory).
>> How realistic and doable is it to abstract that a bit. For example,
>> would an
>> Infinispan based mass indexer make sense? If yes, what's reusable
>> in your
>> impl (I mean aside from the MassIndexer interface).
>>
>> Emmanuel
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
