# Rails: concurrency question

**URL:** <https://www.ruby-forum.com/t/rails-concurrency-question/168895>\
**Category:** Rails\
**Created:** [May 27, 2009, 6:08am UTC](https://www.ruby-forum.com/t/rails-concurrency-question/168895 "2009-05-27T06:08:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![steveybaby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c57346/32.png) [@steveybaby](https://www.ruby-forum.com/u/steveybaby)\
**Post date:** [May 27, 2009, 6:08am UTC](https://www.ruby-forum.com/t/rails-concurrency-question/168895/1 "2009-05-27T06:08:21Z")

</div>

If I have a singleton class (by using the Singleton mixin), I understand  
it’s thread-safe in that it ensures only a single instance of this class  
will be created (by putting a mutex around the instance method). BUT  
(in theory), the instance methods of my singleton instance could be  
accessed concurrently by various threads, thus causing a concurrency  
issue. Right?

BUT Rails is essentially single-threaded (only a single request  
processed at a time), so if I have only a single call to my singleton  
instance method per http request, then it should be impossible to get  
concurrency problems with it. Right?

If I have a cluster 4 servers, then I could have as many as 4 instances  
of my singleton created. But that’s OK – each instance will have its  
own io it writes to. What I don’t want is 20 requests coming in at the  
same time and all trying to use the singleton to write at the exact same  
time.

Are my questions clear enough to answer?

-Steve

---

<div class="post-metadata">

**Author:** ![steveybaby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c57346/32.png) [@steveybaby](https://www.ruby-forum.com/u/steveybaby)\
**Post date:** [May 27, 2009, 11:21am UTC](https://www.ruby-forum.com/t/rails-concurrency-question/168895/2 "2009-05-27T11:21:51Z")

</div>

Your line of reasoning is correct. The only caveat I can see is that  
you’d use Passenger in smart spawning mode, and create the singleton in  
the environment. In this case it’ll be forked and have concurrency  
issues.

–  
Roderick van Domburg  
[http://www.nedforce.com](http://www.nedforce.com)

---

<div class="post-metadata">

**Author:** ![steveybaby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c57346/32.png) [@steveybaby](https://www.ruby-forum.com/u/steveybaby)\
**Post date:** [May 28, 2009, 4:05am UTC](https://www.ruby-forum.com/t/rails-concurrency-question/168895/3 "2009-05-28T04:05:09Z")

</div>

Roderick van Domburg wrote:

> The only caveat I can see is that  
> you’d use Passenger in smart spawning mode

Thank you for the response Roderick!

Also thanks for pointing out the possible concurrency in Passenger. I  
have yet to dive into Passenger, currently using Thin. Anyway the the  
singleton is not created in the environment, so I should be OK even if I  
do choose to leverage Passenger.

Cheers!

-Steve

---

<div class="post-metadata">

**Author:** ![steveybaby](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/c57346/32.png) [@steveybaby](https://www.ruby-forum.com/u/steveybaby)\
**Post date:** [May 30, 2009, 7:26pm UTC](https://www.ruby-forum.com/t/rails-concurrency-question/168895/4 "2009-05-30T19:26:40Z")

</div>

Steve H. wrote:

> BUT Rails is essentially single-threaded (only a single request  
> processed at a time), so if I have only a single call to my singleton  
> instance method per http request, then it should be impossible to get  
> concurrency problems with it. Right?

It’s actually possible to write various kinds of concurrent code in  
Rails – it really ALWAYS was possible to have some concurrency, but not  
concurrent request handling, and whatever concurrency you added you’d  
add yourself.

But in more recent versions of Rails, even some concurrent request  
handling is supported. allow\_concurrency!. And perhaps Passenger in  
certain modes as Roderick says, I’m not familiar with Passenger.

But you’re basically right about the ‘ordinary’ mode of Rails execution,  
that only a single request will be processed at a time. This is  
increasingly not the only option for Rails though.

But, yeah, you’re also right that if you had Rails executing in a mode  
that allowed concurrent request handling, you’d need to take care of  
making sure your singleton object itself is concurrent-access safe –  
the singleton pattern will take care of _instantiation_ of the Singleton  
object being concurrency-safe, but can’t take care of it’s own internal  
logic. So you can either do that – or you can note in comments that  
this thing isn’t concurrency-safe, and shouldn’t be used in a  
concurrent-request environment.
