Rails vs. J2EE: Sharing state in memory?

Rails
1

Hi,

I am from a Java background and pretty new to Ruby and Rails.

What I am wondering is how I would shared state accross requests and
users
without involving IO, i.e. use memory.

My current understanding is that for each request a new process ist
spawn
and therefore it gets its own memory. So no sharing can take place
between
requests?

Do I understand this right? For those who know Java, let me rephrase
that
to prevent missunderstandings?

Is there any equivalent to using the Application Context in J2EE, a
Singleton or static class members to store objects?

Cheers,
Mariano

2

On 12/15/05, Mariano K. [email protected] wrote:

Do I understand this right? For those who know Java, let me rephrase that
to prevent missunderstandings?

Is there any equivalent to using the Application Context in J2EE, a
Singleton or static class members to store objects?

There’s no direct equivalent to that in the CGI model. This isn’t
really a Ruby or Rails thing so much as a ‘Container’ vs. ‘CGI’
difference.
That being said, you can use DRb (Distributed Ruby) as a ‘workalike’
to the application scope you’re used to in Java. DRb does involve
inter-process communication, but it doesn’t require any ‘IO’ if it is
running on the same system as your application.

Objects in application scope can make it hard to scale your app. The
Rails opinion on this is that some fast IO (session stores cached by
your OS or database engine) is a fair trade for making scaling
‘boring’. Still, sometimes they are a good answer to a problem, and
DRb can help you out.

–Wilson.

3

On Thu, 15 Dec 2005, Mariano K. wrote:

Hi,

I am from a Java background and pretty new to Ruby and Rails.

What I am wondering is how I would shared state accross requests and users
without involving IO, i.e. use memory.

there are several ways, not all related to rails:

 - use the database.  a good db running on a box with battery backed

ram is
not goint to hit disk that often. even when it does, caching is
the job
of the database.

 - use shared memory.  using systemvipc in ruby is trivial.

 - use memory.  if you have fastcgi configured for session affinity

you can
ensure that all request travel to the same fastcgi process which,
just in
case you didn’t know, are persistent. therefore a simple
variable can
persist data between requests.

 - use drb.  this elimiates the need for session affinity and makes

your data
available even after the web servers has stopped and restarted.
if drb
uses a unix domain socket the data exchange is very fast, adding
only a
small memcopy in kernel space.

My current understanding is that for each request a new process ist spawn
and therefore it gets its own memory. So no sharing can take place between
requests?

nope. fastcgi is persistent - http://fastcgi.com.

Do I understand this right? For those who know Java, let me rephrase that
to prevent missunderstandings?

Is there any equivalent to using the Application Context in J2EE, a
Singleton or static class members to store objects?

the simple answer is that, under fastcgi, ALL classes have this
ability.

kind regards.

-a

4

let me add, that for example mysql supports memory-based tables that
are completely stored in ram.

it might sound strange that there is no such thing as application state
aka ServletContext. However, it’s part of the paradigm commonly
referred to as ‘share nothing’

i found this as an intro:
http://www.zefhemel.com/archives/2004/09/01/the-share-nothing-architecture

this strategy is really great as it increases the changes of running
your application in cluster with no sweat at all. it will scale very
well.

if database and webserver are on the same machine the performance loss
for using mem-tables is not dramatic.

I am from a Java background and pretty new to Ruby and Rails.
the job
persist data between requests.
spawn
Is there any equivalent to using the Application Context in J2EE, a
Singleton or static class members to store objects?

the simple answer is that, under fastcgi, ALL classes have this
ability.

kind regards.

-a

===============================================================================

| ara [dot] t [dot] howard [at] noaa [dot] gov
| all happiness comes from the desire for others to be happy. all misery
| comes from the desire for oneself to be happy.
| – bodhicaryavatara

===============================================================================

5

this might also be interesting for you:

kind of similar to memory based tables, just noticeably faster…

aka ServletContext. However, it’s part of the paradigm commonly
for using mem-tables is not dramatic.

   not goint to hit disk that often.  even when it does, caching is

variable

   small memcopy in kernel space.

that
-a

===============================================================================

| ara [dot] t [dot] howard [at] noaa [dot] gov
| all happiness comes from the desire for others to be happy. all
misery
| comes from the desire for oneself to be happy.
| – bodhicaryavatara

===============================================================================

6

On 15-dec-2005, at 15:56, Mariano K. wrote:

Do I understand this right? For those who know Java, let me
rephrase that to prevent missunderstandings?

Is there any equivalent to using the Application Context in J2EE,
a Singleton or static class members to store objects?

Sort of (if I correctly decipher what you want).

You can stuff things in a class variable. It’s nasty, it’s dirty and
it might not work in devlepment environment and you will need to
assure session affinity. And the class vars will be for everyone, not
divided by session. And you should be very careful with it because
you might start leaking memory :slight_smile: but this is much more immediate
than other options, which are:

a) Drb (this is what I’d look into)
b) memcache
c) using another frontend framework (Wee or Borges) which is more
“stateful” for parts of the app.