Rails Controller session scope.


Is there a way I can set the scope of my controller class to a session. I don't want to create a new instance of my controller class for each request from a given session.

Please any help would be appreciated.

Thanks, Shishir

Not sure I follow what you’re after. Can you be more specific? Why do you perceive this to be a problem in your situation?

Because, I can't find any way where I can explicitly specify in my controller class to be of the 'session' scope. By default the scope is 'request', as in for every new request from the same session I get a new controller instance created.

Other web frameworks such as JSF have inbuilt methods to specify the scope of the controller class such as 'request', 'session', or 'application', but in rails there is no way i can do that, atleast not anything I am aware of.

Any help would be appreciated.

Thanks, ~Shishir

That still doesn’t answer the question… why do you need to do anything with the scope of the class? why do you think it’s important? I’m not trying to be difficult, I just have never seen it be of any concern in the Rails world.

This isn’t JSF… things just work differently. There’s no need to be concerned with the scope of a class - consider the instance to be per request. Use sessions where appropriate. There are filter methods and other ways to achieve the patter

What I’m getting at is, perhaps you are looking for a solution to a problem that doesn’t really exist. What are you trying to do with your app that would require you to worry about this issue?

OK, I will go in detail of the problem I am facing.

I have a connection object (like say which connects to a chat server such as talk.google.com) as my Model class and which needs to be persisted for all requests generated by a particular session. To begin with, I initialize a model object M1 which holds my connection on the very first request. Now this M1 is the instance I create in the controller instance C1 of first request.

For requests which follow up , I need a reference to this M1 in my controller instances C2, C3, ... which are created for requests coming from the same session. However, there is possibly no direct method of getting reference to M1 in C2, C3 ...etc.

So , what I have to do now is keep a global hash in the controller class and get reference to M1 by calling the hash with a unique key ( which happens to be the userid of the connection) associated with each session. The problem with this approach is I feel it's an unnecessary overhead in terms of processing and memory consumption

1. Because I don't want to waste cpu time in searching the hash every time for every request ( and in my case requests are generated at a very high rate) in order to get reference to my model object.

2. Because every time for a new request from the same session a new controller instance gets instantiated, when all I need is just a single instance of controller for the whole session. This is eating up my memory resource and I don't really trust the garbage collection of the rails framework.

3. Concurrent AJAX requests from the same session get locked and are processed sequentially because each has it's own controller instance.

I hope am more clearer on my problem this time. Please let me know if you need more details/clarifications.

Thanks for your patience.


Look into using BackgrounDrb. What you want to do is not possible in vanilla Rails. BackgrounDrb lets you start up workers that use the Rails environment but are disconnected from the HTTP request/response cycle. Thus, you create a worker that holds open a connection to a chat server and communicate as needed.



+1. This is exactly how you do it.

Brian, Thanks for confirming that but what about the performance issues am wary about.?? Are those justified??


Performance issues? There are no performance issues unless your tests show otherwise. I really can’t answer that question any better because I don’t know how you’re doing what you’re doing. I do not believe it’s anything you’ll have to worry about if you write good code and prepare your environment for scaling. One reason DRB is going to work well for you is that when you have to scale out to multiple machines, storing things the way you’re thinking won’t work across each instance.

This is a whole new ball game, a whole new architecture. Without knowing how it works, it’s not worth worrying about performance issues that might not even be issues. It should take you very little time to set up a proof of concept and test it with some performance testing tools.