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
