Rails - Dec 2009 - Are class variables and class instance variables shared among different requests?

Hi, I just wanted some clarification on this.

In production mode, while I know that object instance variables are
local to the object and so to the request, but is this same with class
variables and class instance variables or are they shared between
requests?

I have this question, because I know that classes are cached in
production mode. But what does this mean? Like, classes are
initialised and cached at the start of the server (and so are class
variables and class level instance variables) and are persistent in
the memory throughout, or it''s like, just class definitions are cached
(so they are not read every time from the disk), and they are re-
initialised for every request, so that every request has its own set?

Say, in file `lib/example.rb` I have defined something like -

  #lib/example.rb
  module Example
  class << self

    def assign value
      @@class_variable = value
      @class_instance_variable = value
    end

    def read
      [@@class_variable, @class_instance_variable]
    end

  end
  end

  #app/controllers/application_controller.rb
  class ApplicationController < ActionController::Base
    before_filter :initialise

    def initialise
      Example.assign params[:name]
    end
  end

1. Request "A" comes with params[:name] as "a".
2. While request "A" executes, request "B" comes with
params[:name] as
"b".
3. Now after arrival of request "B", if code in request "A"
accesses
Example.read(), what would it return? [''b'',
''b''], [''a'', ''a''] or
(maybe, just maybe) [''a'', ''b'']?

I''d also like to write one more example -

  #lib/example.rb
  module Example
  class << self

    @@class_variable = ''default''
    @class_instance_variable = ''default''

    def assign value
      @@class_variable         @class_instance_variable = value
    end

   def read
     [@@class_variable, @class_instance_variable]
   end
  end
  end

1. Request "A" comes, executes Example.assign(''a'')
and finishes.
2. Request "B" comes and tries to execute Example.read(), without
modifying the variables. What would it get? "default" or
"a"?

PS: While writing, I felt like this is a silly question. I''m a novice,
anyway.

- thanks.

--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On Dec 16, 4:12 am, Vikrant Chaudhary
<nas...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Hi, I just wanted some clarification on this.
>
> In production mode, while I know that object instance variables are
> local to the object and so to the request, but is this same with class
> variables and class instance variables or are they shared between
> requests?
>
> I have this question, because I know that classes are cached in
> production mode. But what does this mean? Like, classes are
> initialised and cached at the start of the server (and so are class
> variables and class level instance variables) and are persistent in
> the memory throughout, or it''s like, just class definitions are
cached
> (so they are not read every time from the disk), and they are re-
> initialised for every request, so that every request has its own set?
I believe that the classes actually do stay around, but trying to use
them to pass messages is a Bad Idea. There''s too many ways for any
changes to get lost - a subsequent request might go to a different
worker, the worker with the value might get killed (by hitting memory
limits, or just things like Passenger''s idle timeout, etc). And they
*definitely* go away in development mode, of course.

Note that the typical use of class variables in most of the Rails
source is as a cache of values that should stay constant throughout
execution, which avoids the issue entirely by only setting values
once.

--Matt Jones

--

You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.