I don't think it is viable for gets On Wed, Feb 2, 2011 at 4:25 PM, JL Borges <[email protected]> wrote:
> Yes, I think the least invasive change would be to add the following > methods to ICacheProvider > > void BeginPutCaching() > void BeginGetCaching() > void Flush() > > Providers that don't have pipelining could ignore these. > Those that do support pipelining could store put/get in local > hashtable, then send/request all at once in Flush method. > > Calls to BeginPutCaching/Flush would happen in > Loader.InitializeEntitiesAndCollections > > Calls to BeginGetCaching/Flush would happen in StandardQueryCache.Get, > to optimize > retrieval of query results. > > For locking, it would be nice to have a locking strategy for each > provider. > And we could provide a few ready made strategies: > > NoLockStrategy : does nothing > ReadWriteStrategy: in-process locking > > Then we would simply call > > cache.LockStrategy().Lock() > ... > cache.LockStrategy().Unlock() > > More performant would be: > > cache.LockStrategy().GetReadLock() / > cache.LockStrategy().ReleaseReadLock() > cache.LockStrategy().GetWriteLock() / > cache.LockStrategy().ReleasWriteLock() > > > > > > > > > > > //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > > On Feb 2, 12: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.orgto > > > > 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
