Saiho Y. <sayoyo@…> writes:
Does someone know where exactly the object session is
stored? on the server side or on the client side? And
how rails accesses to that data ( with the
session_id?, where is it exactly?)
and does the session obj is sent to client each time a
request or an answer?
If a user has no session “object” associated with them (for example,
they are
just connecting to your application for the first time), Rails will
automatically, with no code on your part, create a new session data
structure
and save a cookie with it’s identification information into the client
browser.
From then on, every time the client sends an HTTP request to your
application,
it will automatically transmit that session identification cookie to
your
application. Behind the scenes, Rails receives that cookie, maps it to
one of
the currently active session data structures, and makes that structure
available
to your application as the “session[]” hash-like object.
Session data is stored on the server, and is never sent to the
client–all the
client gets is the cookie containing identifying information. The
session id
cookie is set to expire when you close your browser window, so at that
time it
gets deleted. When the user opens a new browser window and connects
again, a new
session is created, it’s identification cookie is created and sent to
the
browser, and the cycle starts all over again.
On the server the session data is stored in a file somewhere; one of
Rails
configuration options lets you change it so it will be stored in a
special table
in your database, in memory, or several other options.
All of this is described in detail in Agile Web D. with Rails,
pages
312-321.
The controllers objects do they recreted each time by
the rails each time it receives a request, or there is
“objects pool” that the controller is stored after it
is created, then wait for a request?
The classes corresponding to your controllers are created when your
Rails
application starts. Every time a new request comes in from the client,
Rails
uses its routing logic to identify which controller should be called,
and then
at the time of the request, it creates an instance of the appropriate
controller class and calls the requested action (method) of that
instance. These
instances are supposed to be discarded when the request processing is
finished;
so there is no “object pool”.
What might be causing some confusion is that if you’re using certain web
server
environments–for example, FastCGI–a pool of copies of the Rails
processes
(dispatch.fcgi) will kept running by the web server, each process
waiting to
receive new requests, and carrying a limited amount of state over from
one
request to the next. Your controller instances will be created and
destroyed
within those processes.
–Forrest