Yes, I think #2 is the best option; most flexible
On Feb 2, 2:09 pm, Fabio Maulo <[email protected]> wrote: > About cache strategies first of all we should implements the Transactional > strategy, then: > > 1) We should remove the restriction of the 3 already available strategies > and give the ability to specify the AssemblyQualifiedName of the concrete > implementation of ICacheConcurrencyStrategy. > This way we will have four embedded strategies but the user will have the > ability to define his own custom implementation. > > 2) The other option is to delegate to the ICacheProvider the instantiation > of the concrete class for each of the four strategies; this way the provider > will have full control of each operation. > > 3) Injectable ICacheFactory through session-factory configuration > > All options can be implemented even together. > > Considering the downloads of NHCH (2% of NH itself) I prefer the > implementation of the option 2 and the remotion of actual CacheFactory. > > > > > > > > > > On Wed, Feb 2, 2011 at 2:27 PM, Fabio Maulo <[email protected]> wrote: > > both (1 and 2) needs a modification of ICacheProvider as: > > bool SupportsMultipleGets > > bool SupportsMultiplePuts > > bool NeedsLocks > > > For multiple get/put I'm not sure if it really needs a modification inside > > the core or if it can be achieved directly inside the provider > > implementation (caching n-puts calls before call the underlining > > multiple-puts). > > If we have to change NH the modification may be in the > > Loader.InitializeEntitiesAndCollections calling the multiple-puts, per > > persister, for all uploaded objects (perhaps the time to implement > > a InitializeEntityEventListener has come). > > > On Wed, Feb 2, 2011 at 2:04 PM, JL Borges <[email protected]> wrote: > > >> Let's deal with this issue on its own merits. > > >> This is about cache concurrency strategy and ICache interface. > > >> Cache concurrency strategy is currently fixed to three different > >> strategies at the moment. > >> ICache interface is fixed. > > >> Proposal: > > >> 1) refactor concurrency strategies to avoid unnecessary locking for > >> distributed caches > >> 2) refactor ICache to support multiple get/put > > >> Of course, all cache providers will have to do some work to support > >> the refactor. > > >> Kind Regards, > >> JL Borges > > >> On Feb 2, 10:49 am, Fabio Maulo <[email protected]> wrote: > >> > Only, I would know with who I'm talking. > > >> > One of the previous question (using the name Aaron) was about add locks > >> for > >> > no-thread-safe cache system. > >>https://groups.google.com/group/nhibernate-development/browse_thread/... > > >> > < > >>https://groups.google.com/group/nhibernate-development/browse_thread/.. > >> .>Cache > >> > providers are injectable pieces and can be published whatever where you > >> want > >> > and Jorge/Aaron/JLBorges can ask permissions to blog in nhforge.org to > >> > promote his providers. > > >> > In this case Jorge/Aaron/JLBorges is asking about an "improvement" of > >> > ICache: we can discuss it, no problem, but I would be sure that it is > >> really > >> > needed. > > >> > On the other hand we have to port some other features, about cache, from > >> > Hibernate as IsMinimalPutsEnabledByDefault and some other where needed > >> > (read/update). > > >> > On Wed, Feb 2, 2011 at 12:19 PM, Ramon <[email protected]> wrote: > > >> > > Fabio, > > >> > > What exactly is your problem? He is just asking some questions and you > >> > > respond with such weird stuff. I dont get it. > > >> > > On Wed, Feb 2, 2011 at 4:13 PM, Fabio Maulo <[email protected]> > >> wrote: > > >> > >> Hi Jorge/Aaron/JLBorges (same e-mail different name/sign) > > >>http://groups.google.com/group/nhcdevs/browse_thread/thread/ebb6a1160... > > >>http://groups.google.com/group/nhcdevs/browse_thread/thread/8d6b58b14... > > >>http://groups.google.com/group/nhcdevs/browse_thread/thread/a3f9bf2ab... > > >>http://groups.google.com/group/nhibernate-development/browse_thread/t... > > >> > >> and continuing counting... > > >> > >> - Show quoted text - > > >> > >> On Wed, Feb 2, 2011 at 12:03 PM, JL Borges <[email protected]> > >> wrote: > > >> > >>> Hello All, > > >> > >>> I've been hacking the NH L2 cache for a few months, and I have come > >> > >>> to the conclusion that it is not really designed for distributed > >> > >>> caches. > > >> > >>> Here are the issues I am concerned about: > > >> > >>> 1) Server Round Trip > > >> > >>> With a distributed cache, a lot of the time is spent > >> sending/receiving > >> > >>> data over > >> > >>> the socket, so performance increases dramatically when these > >> > >>> roundtrips are reduced. Many modern distributed caches, like > >> > >>> Memcached and Redis, support client-side pipelining, where multiple > >> > >>> gets or puts are sent in one socket call. The NH ICache interface > >> does > >> > >>> not support multiple puts or gets, so this feature is not available. > > >> > >>> 2) Locking > > >> > >>> a) If a distributed cache supports distributed locks, then there is > >> no > >> > >>> need for an in-process lock, and it just harms performance. And yet, > >> > >>> here is a code snippet from the > >> > >>> ReadWriteCache concurrency strategy > > >> > >>> lock (_lockObject) > >> > >>> { > >> > >>> if (log.IsDebugEnabled) > >> > >>> { > >> > >>> log.Debug("Caching: " + key); > >> > >>> } > >> > >>> try > >> > >>> { > >> > >>> cache.Lock(key); > >> > >>> . > >> > >>> . > >> > >>> . > > >> > >>> b) distributed locks can fail due to timeout or server crashing > >> after > >> > >>> acquiring the lock. > >> > >>> There is no logic here to support this. > > >> > >>> I have a patch to address these issues, in my own NH fork. I've also > >> > >>> submitted a patch to JIRA to add distributed locks to the Enyim > >> > >>> memcached client. No response so far. > > >> > >>> Is there any interest in improving support for distributed caches? > > >> > >>> Cheers, > >> > >>> JL Borges > > >> > >> -- > >> > >> Fabio Maulo > > >> > -- > >> > Fabio Maulo > > > -- > > Fabio Maulo > > -- > Fabio Maulo
