Ok, thanks for advice. I think it has as each DP has an access to SearchFactoryImplementor
2009/8/20 Emmanuel Bernard <emman...@hibernate.org> > > > On 20 août 2009, at 13:25, Łukasz Moreń <lukasz.mo...@gmail.com> wrote: > > Yes, that's right, and also CM can close all its caches. If CM is single > per HS start it could be stored as a field somewhere in > SearchFactoryImplementor, but code won't be too clean then. > > > I don't want that. That would be pure pollution :) > > Another idea is to add non-static CM field to IspnDirectoryProvider and it > will be initialized by first indexed entity that use such directory. Next > entities will get CM from DP already initialized and stored > in SearchFactoryImplementor. > > > That's one way. Try and explore that by having a specific interface for dir > providers that expose CMs > > I am not sure though that a dp has access to other dps > > > > 2009/8/20 Emmanuel Bernard < <emman...@hibernate.org> > emman...@hibernate.org> > >> Well except that if a CM has many Caches, you can close it only when the >> last cache is closed. You can do that by keeping sone kind of counter >> >> >> On 20 août 2009, at 11:08, Łukasz Moreń < <lukasz.mo...@gmail.com> >> lukasz.mo...@gmail.com> wrote: >> >> Hmm, I have to think more about that. Caches close when DirectoryProvider >> stops, so CM could be also. >> >> 2009/8/20 Emmanuel Bernard < <emman...@hibernate.org><emman...@hibernate.org> >> emman...@hibernate.org> >> >>> I don't want static code in HSearch if we can avoid that. It always >>> creates unexpected issues. (In this case units tests will be quite messy at >>> least). Plus Caches and CacheManager don't have to be closed? They might >>> need to be tied to the HSearch lifecycle or something. >>> >>> >>> On 20 août 09, at 09:18, Łukasz Moreń wrote: >>> >>> >>> >>> 2009/8/20 Emmanuel Bernard < >>> <emman...@hibernate.org><emman...@hibernate.org> >>> emman...@hibernate.org> >>> >>>> >>>> On 18 août 09, at 17:35, Łukasz Moreń wrote: >>>> >>>> Now, every directory provider creates new Infinispan CacheManager - >>>> factory for caches. Each manager creates cache with defined name. Caches >>>> with this same name make distributed one, so we can have one common cache, >>>> cache per directory, depends how they are named - that way cache is shared. >>>> This is really not efficient since heavy CacheManager is created with every >>>> indexed entity - ideally one per VM. The better idea I think is to >>>> share one CacheManager between all directories in node. >>>> >>>> >>>> OK >>>> >>>> Then shared are also caches objects locally - not like previously every >>>> time is created new one. >>>> >>>> >>>> I don't understand that sentence, can you detail a bit further. >>>> >>> >>> >>> If one CM is used per VM: cache with defined name is created, then if we >>> want to get cache with this same name, new one is not created, we get >>> reference to existing one. So if we set up one shared cache for all >>> directories, locally we work on this same object. >>> Before with CM per lucene directory always each CM created new cache - >>> and they made connection, so even from same VM, data was send over the >>> network:). >>> >>> >>> >>>> >>>> HSearch started twice, independently, that both instances don't share >>>> resources - directories.? E.g. every time with different configuration? >>>> >>>> >>>> Yes, if you start HSearch twice, they should be totally independent (ie >>>> not share resources like CacheManager etc. >>>> >>>> To achieve that can be either created new CacheManager every HS start, >>>> or used one, but with different cache names per app. >>>> >>>> >>>> I like one CM per HS start but how do you think you can achieve that? >>>> >>> >>> Actually I was thinking about one CM per app. Altough I think we can >>> maybe store CM's in some static Map and start HS every time with different >>> Infinispan setting: cluster name. Then cluster name could be a map's key. >>> >>>> >>>> >>>> >>>> 2009/8/14 Emmanuel Bernard < >>>> <emman...@hibernate.org><emman...@hibernate.org> >>>> emman...@hibernate.org> >>>> >>>>> How do you share the cache between different directories? A static >>>>> field would not work well as it would prevent HSearch to be started twice >>>>> in >>>>> a single app. >>>>> >>>>> Anyway if we share the cache, I would still like to use the per >>>>> directory provider configuration strategy (from a config property point of >>>>> view) and raise an exception if it turns out the Infinispan cache config >>>>> is >>>>> different between two different indexes. That way we can improve down the >>>>> road. >>>>> >>>>> On 14 août 09, at 05:33, Łukasz Moreń wrote: >>>>> >>>>> There is one cache for all indexes. In this case scoping configuration >>>>> will be hard.Yes, some default config will be provided. Right, >>>>> different propterties for xml and programmatic would be better. >>>>> >>>>> 2009/8/14 Emmanuel Bernard < >>>>> <emman...@hibernate.org><emman...@hibernate.org> >>>>> emman...@hibernate.org> >>>>> >>>>>> Question, >>>>>> Do we have one cache for all indexes (directories) or one per >>>>>> directory? >>>>>> >>>>>> I feels wrong to see this configuration not scoped per index >>>>>> hibernate.search.default.directory_provider >>>>>> blah.blah.InfinispanDirectoryProvider >>>>>> hibernate.search.default.infinispan_conf com.acme.CacheFactoryImpl >>>>>> >>>>>> hibernate.search.Address.directory_provider >>>>>> blah.blah.InfinispanDirectoryProvider >>>>>> hibernate.search.Address.infinispan_conf conf.xml >>>>>> >>>>>> hibernate.search.User.directory_provider >>>>>> blah.blah.InfinispanDirectoryProvider >>>>>> hibernate.search.User.infinispan_conf auto >>>>>> >>>>>> As Sanne pointed out, maybe we want different properties for XML, >>>>>> programmatic and built-in configs. I kinda like the idea of one config >>>>>> but >>>>>> it seems it will be hard to differenciate a class from a config file. >>>>>> >>>>>> Emmanuel >>>>>> >>>>>> >>>>>> On 13 août 09, at 18:33, Łukasz Moreń wrote: >>>>>> >>>>>> I was thinking that maybe we can expose full conf options. >>>>>>> Infinispan supports programmatical and xml ways to configure cache. >>>>>>> To achieve first one, could be created some interface with factory >>>>>>> method that returns cache. User can implement that and create cache as >>>>>>> he >>>>>>> wants. >>>>>>> >>>>>>> Something like that: >>>>>>> >>>>>>> <property name="hibernate.search.infinispan.conf" >>>>>>> value="org.hibernate.search.store.infinispan.CacheFactoryImpl" /> >>>>>>> >>>>>>> and for xml >>>>>>> >>>>>>> <property name="hibernate.search.infinispan.conf" >>>>>>> value="xml-conf.xml" /> >>>>>>> >>>>>>> >>>>>>> Exposing some configuration to infinispan makes sense. can you start >>>>>>> a thread explainig what is configurable and which one you think we >>>>>>> should >>>>>>> expose to hsearch users. Ideally I would like to offer one or two defaut >>>>>>> config scenarios and allow to fallback to a custom config. >>>>>>> >>>>>>> Cheers, >>>>>>> Lukasz Moren >>>>>>> _______________________________________________ >>>>>>> hibernate-dev mailing list >>>>>>> <hibernate-dev@lists.jboss.org> <hibernate-dev@lists.jboss.org> >>>>>>> hibernate-dev@lists.jboss.org >>>>>>> >>>>>>> <https://lists.jboss.org/mailman/listinfo/hibernate-dev><https://lists.jboss.org/mailman/listinfo/hibernate-dev> >>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
