On Fri, Sep 20, 2013 at 3:10 PM, Florian Apolloner
<[email protected]> wrote:
> The main issue here isn't recreating the objects on demand, but the impact
> they have, eg a new memcached connection. Now imagine a complex system where
> each part issues get_cache('something') to get the cache
On the other hand each call to get_cache('foo') now requires access to
TLS. TLS is sloooow. Going through something slow to get to something
that is supposed to be a speed up...
> and you'll end up
> with a few connections per request instead of one.
Would it be better to leave the API and semantics of get_cache alone
and provide a new way of accessing caches through the request object,
leaving them cached on the request object for the duration of the
request, and thus avoiding the need of TLS.
The reason to use TLS is because requests are commonly served from
threaded servers, and cache clients may not be thread safe, so a
desire to stop different requests from simultaneously accessing the
same cache client. Requests aren't shared between threads, and so a
per request cache would be inherently thread safe.
It seems more sensible to hook something that has the lifetime of the
request to the request, rather than stick it in TLS, keyed to the
thread serving the request.
Cheers
Tom
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
For more options, visit https://groups.google.com/groups/opt_out.
