Thanks you very much for the information!!!!!
Saiho
--- Forrest Thiessen
<thiessen-I0D8NflN0vzU+KD/reu1CkEOCMrvLtNR@public.gmane.org>
wrote:
> Saiho Yuen <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
> Development 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
>
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
If God really exists, I would like to
know what the dinosaurs have done to
deserve their extinction.
Water is unknown to fishes,
until they discover air.
http://www.geocities.com/sayoyo/
__________________________________
Yahoo! Mail - PC Magazine Editors'' Choice 2005
http://mail.yahoo.com