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
