Per-request in memory cache for all communication with the MemCache server(s)

Ah, it's not thread safe - working on that now.

I totally dig the idea of this. It's similar to what Nick Kallen's cache_money plugin does:

http://github.com/nkallen/cache-...

The main thing that bothers me about the implementation in this patch is that it knows about Action Controller. The cache store shouldn't know Action Controller even exists. I'd much rather there be a facility to tell the cache store to use the local cache or not, such that we could declare the setting from AC's side.

Jeffrey, I totally agree with you on the subject of the class knowing about ActionController. In fact my delay in updating this ticket with a thread safe version is because I've been trying to solve that problem nicely.

I like simply going:

config.action_controller.session_store = :mem_cache_store

to setup memcache in rails. I don't really want people to have to do extra things to get it going when it should just work seamlessly without any effort. At the moment it still depends on AC.

Doing the local caching actually solves a bug in rails, something I've not directly said above. It stops the problem of entries in memcache changing in between the execution of the action and view code. I've had this happen a number of times, pain in the butt to track down. I probably should have tagged this with bug too maybe...

Anyway, I've attached an updated patch with my changes being thread safe now plus a minor fix to the 'exist?' method.

Just to clariy for those reading, the dependency on ActionController is because MemCacheStore hooks into the Dispatcher before_dispatch callback to clear the local cache before each request is processed.

Hey, I just commit it.

I made some changes, it uses a thread local instead of a lock. Should be much less overhead.

Please review and make sure it still functions how you want.

Will do thanks for doing that. I'll look at it right now. (Clients discovered I had spare time :-(

Yep, functions as intended. :-)

Oh and thanks for giving it some polish Joshua.

Interesting comments on github:

http://github.com/rails/rails/co...

Maybe it should be a subclass or extension module?

Josh,

Initial backend agnostic local cache strategy attached.Introduced an ActiveSupport::Cache::Strategy::* namespace, which may be frowned upon, but may be useful for similar optimizations.

Original test cases passes.

@ Josh,

Am aware of two apps where the immutable snippet in #read raises with TypeError when the value being dup'ed is a special case constant eg. Fixnum, TrueClass etc.

Here's the reference to the MRI implementation of Object#clone, Object#dup ( object.c ) && the special constant declaration ( ruby.h ) from a 187 checkout :

http://gist.github.com/54069

Attached is a patch that implements Object#dup? to better handle such cases.

Thoughts ?

• Lourens

Updated diff for Object#clone?

Maybe we could just add dup to Integer and just return self?

@ Josh,

Interesting, but isn't it dodgy practice to mask the TypeError in non-framework code VS being able to conditionally guard against it in specific framework areas, like the local cache, to not blow up the whole process when that happens ?

Josh,

Nevermind, references :

"* object.duplicable? returns true if object.dup is safe. False for nil, true, false, symbols, and numbers; true otherwise. #9333 [sur]"

Patch that piggy backs on that attached.

(from [2e69db18ce2815c25eee64fc2978e7f6b57f6e1f]) Only dup local cache values if duplicable [#1653 Per-request in memory cache for all communication with the MemCache server(s) state:resolved] http://github.com/rails/rails/co...