On Thu, Feb 10, 2011 at 1:54 PM, Tom Evans <[email protected]> wrote: > I've updated the ticket with a patch against trunk implementing uuid > session keys....
One of the reasons why it was coded like this was because you can not tell the difference in the cache backend between a key collision and memcache being unavailable (as I read the comments). This is why it will try 10,000 times to come up with a key before bailing. With this switching the key to a UUID, the chance of collision is so tiny as to be discounted, should this logic be changed slightly, so that if the cache is not there, we don't go to the effort of generating 10,000 UUIDs and trying to update a non-functioning memcache instance? Would we still want to try a 'reasonable' number of times, to allow memcache to recover? Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
