Rails - Dec 2005 - Rails vs. J2EE: Sharing state in memory?

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


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

On 12/15/05, Mariano Kamp
<mariano.kamp-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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.

On Thu, 15 Dec 2005, Mariano Kamp 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
-- 
==============================================================================|
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
==============================================================================
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

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.
> --- Ursprüngliche Nachricht ---
> Von: ara.t.howard-32lpuo7BZBA@public.gmane.org
> An: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Betreff: Re: [Rails] Rails vs. J2EE: Sharing state in memory?
> Datum: Thu, 15 Dec 2005 10:10:11 -0700 (MST)
> 
> On Thu, 15 Dec 2005, Mariano Kamp 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
> -- 
>
==============================================================================>
| 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
>
==============================================================================>

this might also be interesting for you:

http://www.danga.com/memcached/
http://www.deveiate.org/projects/RMemCache/

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

> --- Ursprüngliche Nachricht ---
> Von: "Peter Ertl" <pertl-BA+cFGlbTmA@public.gmane.org>
> An: ara.t.howard-32lpuo7BZBA@public.gmane.org,
rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> Betreff: Re: [Rails] Rails vs. J2EE: Sharing state in memory?
> Datum: Thu, 15 Dec 2005 18:18:23 +0100 (MET)
> 
> 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.
> 
> > --- Ursprüngliche Nachricht ---
> > Von: ara.t.howard-32lpuo7BZBA@public.gmane.org
> > An: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> > Betreff: Re: [Rails] Rails vs. J2EE: Sharing state in memory?
> > Datum: Thu, 15 Dec 2005 10:10:11 -0700 (MST)
> > 
> > On Thu, 15 Dec 2005, Mariano Kamp 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
> > -- 
> >
>
==============================================================================>
> | 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
> >
>
==============================================================================>
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

On 15-dec-2005, at 15:56, Mariano Kamp 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.
>
>   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?
>
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 :-) 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.