# Concurrency problem with memcached fragments mongrel cluster

**URL:** <https://www.ruby-forum.com/t/concurrency-problem-with-memcached-fragments-mongrel-cluster/77484>\
**Category:** Rails\
**Created:** [November 28, 2006, 9:27am UTC](https://www.ruby-forum.com/t/concurrency-problem-with-memcached-fragments-mongrel-cluster/77484 "2006-11-28T09:27:15Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@sam](https://www.ruby-forum.com/u/sam)\
**Post date:** [November 28, 2006, 9:27am UTC](https://www.ruby-forum.com/t/concurrency-problem-with-memcached-fragments-mongrel-cluster/77484/1 "2006-11-28T09:27:15Z")

</div>

Hi,

I have the following question: What happens when you memcache fragments  
and you are running with a mongrel cluster. In the case when we check  
read\_fragment() in our action/controller and by the time Rails rechecks  
to see if the fragment exists in the view, the fragment could have  
possibly expired in memcache, or could have gotten deleted if you are  
running some expiration sweeper of some sort. This means that none of  
the instance variables or SQL was run since read\_fragment() returned  
true saying there is a fragment. Does this mean view rendering will  
crash because it would try to create the cache block? How does one fix  
this window if this is a problem? How do multiple mongrels synchronize  
around this shared fragment?

Thanks.

---

<div class="post-metadata">

**Author:** ![sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@sam](https://www.ruby-forum.com/u/sam)\
**Post date:** [November 28, 2006, 5:53pm UTC](https://www.ruby-forum.com/t/concurrency-problem-with-memcached-fragments-mongrel-cluster/77484/2 "2006-11-28T17:53:38Z")

</div>

> around this shared fragment?  
> This could very well happen, but if your memcache ram size is large  
> enough  
> and you’ve told it not to expire, probably won’t.

But…memcache is _not_ permanent storage… they make that very clear.  
So if you’re relying on it being there long term, well… don’t.

🙂

---

<div class="post-metadata">

**Author:** ![sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@sam](https://www.ruby-forum.com/u/sam)\
**Post date:** [November 28, 2006, 8:10pm UTC](https://www.ruby-forum.com/t/concurrency-problem-with-memcached-fragments-mongrel-cluster/77484/3 "2006-11-28T20:10:14Z")

</div>

Yes this could happen as well, but if your cache size is large enough,  
it’ll  
happen probably about one in a million times. Can’t think of a way  
around  
this.

Vish

---

<div class="post-metadata">

**Author:** ![sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@sam](https://www.ruby-forum.com/u/sam)\
**Post date:** [November 28, 2006, 9:02pm UTC](https://www.ruby-forum.com/t/concurrency-problem-with-memcached-fragments-mongrel-cluster/77484/4 "2006-11-28T21:02:31Z")

</div>

My understanding is that memcached uses LRU, so calling read\_fragment()  
will  
push the fragment to the top of he used list. This should give it a  
good  
chance of surviving until you use it in the view. However, you should  
check  
out extended\_fragment\_cache [1]. Though I have never used it, I believe  
when calling read\_fragment(), it saves the cached fragment in an  
in-process  
cache. This would in theory cut down on the number of cache queries,  
and  
possibly guarantee that the fragment exists (in the in-process cache)  
when  
you hit the view. I found this extension through Tyler Kovaks’ slides  
titled “Efficient Memcached Usage” [2] (check out slide 8/11).

[1]  
[http://www.gemjack.com/gems/extended\_fragment\_cache-0.0.1/files/home/tony/projects/gemjack/gems/tmp/lib/extended\_fragment\_cache\_rb.html](http://www.gemjack.com/gems/extended_fragment_cache-0.0.1/files/home/tony/projects/gemjack/gems/tmp/lib/extended_fragment_cache_rb.html)  
[2] [http://sparecycles.org/efficient\_memcached\_usage/index.html](http://sparecycles.org/efficient_memcached_usage/index.html)