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,
just connecting to your application for the first time), Rails will
automatically, with no code on your part, create a new session data
and save a cookie with it’s identification information into the client
From then on, every time the client sends an HTTP request to your
it will automatically transmit that session identification cookie to
application. Behind the scenes, Rails receives that cookie, maps it to
the currently active session data structures, and makes that structure
to your application as the “session” hash-like object.
Session data is stored on the server, and is never sent to the
client gets is the cookie containing identifying information. The
cookie is set to expire when you close your browser window, so at that
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
browser, and the cycle starts all over again.
On the server the session data is stored in a file somewhere; one of
configuration options lets you change it so it will be stored in a
in your database, in memory, or several other options.
All of this is described in detail in Agile Web D. with Rails,
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
application starts. Every time a new request comes in from the client,
uses its routing logic to identify which controller should be called,
at the time of the request, it creates an instance of the appropriate
controller class and calls the requested action (method) of that
instances are supposed to be discarded when the request processing is
so there is no “object pool”.
What might be causing some confusion is that if you’re using certain web
environments–for example, FastCGI–a pool of copies of the Rails
(dispatch.fcgi) will kept running by the web server, each process
receive new requests, and carrying a limited amount of state over from
request to the next. Your controller instances will be created and
within those processes.