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> > 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> > >> >> 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> >> >>> 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> >>> >>>> 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 >>>>> 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
