Rails Controller session scope

Rails
1

Hi,

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

2

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?

3

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

4

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?

5

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.

~Shishir

6

+1. This is exactly how you do it.

7

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.

http://backgroundrb.rubyforge.org/

Jason

8

Shishir:

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.

9

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