Scope of a global

If I set a global can it be access from all instances of Rails (on the
same application server)?

By instances of Rails I mean for each user who use the application?

Many thanks, K.

To clarify:

  1. User A logs in and enters a number in to an input box and hits submit
  2. The controller stores the submitted value in a global
  3. User B logs in, can this user see the value submitted by user A

I know I could store the value in the database or on file but this is
not approprite for the purpose, the value needs to be sharded across
users and in memory.

Many thanks, K.

Kris L. wrote:

To clarify:

  1. User A logs in and enters a number in to an input box and hits submit
  2. The controller stores the submitted value in a global
  3. User B logs in, can this user see the value submitted by user A

I know I could store the value in the database or on file but this is
not approprite for the purpose, the value needs to be sharded across
users and in memory.

Many thanks, K.

hello list, i am new here…

actually, i am JUST about to start my first rails app… got the agile
and pickaxe books, and i got a handle on things… but i need to do
precisely this…

in my case, part of my app just grabs POST requests… and puts the data
into a hash… when that hash gets to about 100 items or so, it will dump
to another hash, then unload that hash into a database…

i need this to be fairly quick moving, so i don’t want to write to the
database every time i get a request (plus, it will have a pretty high
hit rate off and on…)

i will follow this topic… thanks!

Kris wrote:

If I set a global can it be access from all instances of Rails (on the
same application server)?

By instances of Rails I mean for each user who use the application?

No, that won’t work. Each HTTP request spawns a new Rails environment
that shares nothing with other requests. Globals and class variables are
not seen by other Rails instances. If you want to share data between
requests, you have to use the session, the database, or a caching
approach such as memcache.

The session is probably the easiest way to go.

http://wiki.rubyonrails.com/rails/pages/HowtoWorkWithSessions


Josh S.
http://blog.hasmanythrough.com

Josh S. wrote:

Each HTTP request spawns a new Rails environment
that shares nothing with other requests. Globals and class variables are
not seen by other Rails instances. If you want to share data between

Hi Josh,

Isn’t that only true for good old CGI ? I thought under FCGI there was
a single Ruby interpreter running for, effectively, the duration.

(not disagreeing, just trying to understand :slight_smile:

A.

Hi Kris / Sergio / ?

  1. User A logs in and enters a number in to an input box and hits submit
  2. The controller stores the submitted value in a global
  3. User B logs in, can this user see the value submitted by user A

Globals in RoR are, as they are in any other language / environment I’ve
ever worked in, global to the application. So on face value, assuming
the
visitors above are both using the same application (i.e., web site), the
answer to your question is ‘yes.’ But I wonder if I understand your
question.

hth,
Bill

The session is probably the easiest way to go.

my only question on the sessions is…

aren’t session variables tied to the each session only?

so if i have a session variable named ‘username’

and another user somewhere else starts a session and a variable
‘username’ is created…

they would poth point to different values…

i think i am missing something, but hey, i am new…

Alan F. wrote:

Josh S. wrote:

Each HTTP request spawns a new Rails environment
that shares nothing with other requests. Globals and class variables are
not seen by other Rails instances. If you want to share data between

Hi Josh,

Isn’t that only true for good old CGI ? I thought under FCGI there was
a single Ruby interpreter running for, effectively, the duration.

(not disagreeing, just trying to understand :slight_smile:

No. The share-nothing architecture is fundamental to Rails. FCGI
maintains a Ruby process so that it doesn’t have to restart that, but
the Rails state is still initialized for each request.


Josh S.
http://blog.hasmanythrough.com

You didn’t miss something, session state is for a particular user. If
you want to share data among all users, you need to use the database or
something like memcache. If you’re only running on one server you could
use the file system, but that’s a bit of a hack.

i wil lproably have to use memcache…

maybe for the first iterations, i will try my like with writes to the
database, and see if that works…

thanks!

sergio ruiz wrote:

The session is probably the easiest way to go.

my only question on the sessions is…

aren’t session variables tied to the each session only?

so if i have a session variable named ‘username’

and another user somewhere else starts a session and a variable
‘username’ is created…

they would poth point to different values…

i think i am missing something, but hey, i am new…

You didn’t miss something, session state is for a particular user. If
you want to share data among all users, you need to use the database or
something like memcache. If you’re only running on one server you could
use the file system, but that’s a bit of a hack.


Josh S.
http://blog.hasmanythrough.com

“Bill” == Bill W. [email protected] writes:

That, however, begs the question… so what is a Global variable in
Rails global to, exactly?

Global variables are a Ruby feature that has little or no use in Rails.

	     Calle D. <[email protected]>
	 http://www.livejournal.com/users/cdybedahl/
  "Data on the network has cooties and will EAT YOUR BRAINS"
		   -- Ross Younger, BofhNet

Hi Josh,

Globals and class variables are
not seen by other Rails instances.

Interesting. I thought I’d read about their use (not recommendation to
use)
in AWDwR but can’t find the cite, so I guess I was wrong. That,
however,
begs the question… so what is a Global variable in Rails global to,
exactly?

Thanks,
Bill

Calle D. wrote:

“Bill” == Bill W. [email protected] writes:

That, however, begs the question… so what is a Global variable in
Rails global to, exactly?

Global variables are a Ruby feature that has little or no use in Rails.

I guess that answers my question, but I dont get how/why Rails can
override the behaviour of Ruby.

When a Rails application (or any ruby script) is accessed by a user is a
new interpreter instance started up or is the same instance always used?


Calle D. [email protected]
http://www.livejournal.com/users/cdybedahl/
“Data on the network has cooties and will EAT YOUR BRAINS”
– Ross Younger, BofhNet

On Saturday 17 June 2006 11:51, Justin F. wrote:

I guess that answers my question, but I dont get how/why Rails can

If you have more than one FCGI process, each will have its own global
variable.

That’s what I thought. So in the original poster’s case, with a
multi-fcgi-process setup, user B sometimes sees user A’s data, while
user
A himself might not see his own data more often than not :slight_smile:

I’d go with the DB write. That’s safe, not as slow as one might expect,
and if the site gets enough traffic to cause a bottleneck there, it
should have enough resources to throw more hardware at the problem.

kris wrote:

new interpreter instance started up or is the same instance always used?
Rails doesn’t override the behaviour of Ruby. Global variables are
global to the Ruby process. If you have a single process running Rails,
e.g. WEBrick or a single FCGI process, a global variable will behave in
the way you would expect (e.g. you can use it as a request counter).

If you have more than one FCGI process, each will have its own global
variable. Not generally useful at the application level, but could be
used e.g. for monitoring how the load is being distributed across the
processes.

If you try the same with class variables, you will find that in
development the class is reloaded on every request (regardless of
whether or not it has changed), so the class variable keeps getting
reset. In production, this doesn’t happen - the class variable behaves
more like a global variable.

I tested this in WEBrick before writing this mail (it’s a lot less
typing to test it than to explain it!)

regards

Justin