Global Data, where can it go?


#1

I’m developing a stateful Ruby application that needs to keep data in
one location where all people accessing the site can modify its
contents. This data will be read-from/written to often, so I would
prefer for rails to keep it in memory, rather than a database.

My frist try involved global variables. After discovering that they
were being “re-initialized” with each new user, I put something like
this in the application controller:

if not $global
$global = []
end

But, then I had the problem with only certain pages being able to access
them. With the above code in my controller, I could not access it from
the model, only the view.

Are there good ways to keep dynamic data in a central, location
available site-wide?

Thanks in advance for the help.

-Dustin


#2

i just drop global variables (use them very sparingly) in my
applications.rb controller like

$Admins = [‘user1’,‘user2’]

sort of thing. $Admins is now available to any controller or view

adam


#3

On Jan 25, 2006, at 12:17 AM, Dustin wrote:

$global = []

Thanks in advance for the help.

-Dustin

Dustin-

This looks like a job for distributed ruby or DRb. You can use a drb

server that runs on a high port number and published a hash. Then in
your rails app you can access the hash just like a normal object and
store and lookup whatever you want in it. This way you can have one
process that handles your state data that is outside the rails app
and is persistent between requests.

Here is an example:

drb_server.rb:

require ‘drb/drb’

DRb.start_service(‘druby://127.0.0.1:13500’, Hash.new)
puts DRb.uri
DRb.thread.join

Now to use this lets just look at an irb example for the client. You

can put this code somewhere in your rails app to initialize the Drb
objects and get the hash. Here’s a simple example:

ezra:~ ez$ irb
irb(main):001:0> require ‘drb/drb’
=> true

irb(main):002:0> DRb.start_service
=> #<DRb::DRbServer:0x206e64 @front=nil, @config=
{:tcp_acl=>nil, :idconv=>#<DRb::DRbIdConv:
0x20e344>, :argc_limit=>256, :verbose=>false, :load_limit=>26214400},
@grp=#ThreadGroup:0x206d24, @thread=#<Thread:0x206978 sleep>,
@protocol=#<DRb::DRbTCPSocket:0xd17a8 @acl=nil, @config=
{:tcp_acl=>nil, :idconv=>#<DRb::DRbIdConv:
0x20e344>, :argc_limit=>256, :verbose=>false, :load_limit=>26214400},
@msg=#<DRb::DRbMessage:0xd0e84 @argc_limit=256,
@load_limit=26214400>, @socket=#TCPServer:0xd4570, @uri=“druby://
ezra.local:61721”>, @idconv=#DRb::DRbIdConv:0x20e344, @uri=“druby://
ezra.local:61721”>

irb(main):003:0> test = DRbObject.new(nil, ‘druby://127.0.0.1:3500’)
=> #<DRb::DRbObject:0x509f64 @ref=nil, @uri=“druby://127.0.0.1:3500”>

irb(main):004:0> test
=> #<DRb::DRbObject:0x509f64 @ref=nil, @uri=“druby://127.0.0.1:3500”>

irb(main):005:0> test = {:foo =>‘bart bart’, :bar => ‘niknik’}
=> {:foo=>“bart bart”, :bar=>“niknik”}

irb(main):006:0> test[:foo]
=> “bart bart”

irb(main):009:0> test.merge!({:mydata => {:title => ‘testing
drb’, :description => ‘a distributed hash object to use in my rails
apps!’}})
=> {:foo=>“bart bart”, :bar=>“niknik”, :mydata=>{:title=>“testing
drb”, :description=>“a distributed hash object to use in my rails
apps!”}}

irb(main):010:0> test
=> {:foo=>“bart bart”, :bar=>“niknik”, :mydata=>{:title=>“testing
drb”, :description=>“a distributed hash object to use in my rails
apps!”}}

irb(main):011:0> test[:mydata][:title]
=> “testing drb”

Hope that helps you. Stay tuned as I will soon be releasing a plugin
the publishes remote stand alone ActiveRecord models. These can be
used for long running processes that take too long to be in the
request response cycle.

Cheers-
-Ezra Z.
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
removed_email_address@domain.invalid


#4

You might want to check out a shared cache solution, like memcached.

http://www.ruby-forum.com/topic/51948#24014
http://wiki.rubyonrails.org/rails/pages/MemCached
http://wiki.rubyonrails.org/rails/pages/Action+Cache+Update+Plugin

Dustin wrote:

I’m developing a stateful Ruby application that needs to keep data in
one location where all people accessing the site can modify its
contents. This data will be read-from/written to often, so I would
prefer for rails to keep it in memory, rather than a database.

My frist try involved global variables. After discovering that they
were being “re-initialized” with each new user, I put something like
this in the application controller:

if not $global
$global = []
end

But, then I had the problem with only certain pages being able to access
them. With the above code in my controller, I could not access it from
the model, only the view.

Are there good ways to keep dynamic data in a central, location
available site-wide?


#5

This looks like a job for distributed ruby or DRb. You can use a drb
server that runs on a high port number and published a hash. Then in
your rails app you can access the hash just like a normal object and
store and lookup whatever you want in it. This way you can have one
process that handles your state data that is outside the rails app
and is persistent between requests.

This is truly interesting. Is any performance hit to be expected?


#6

On Jan 25, 2006, at 9:14 AM, Juan Lupión wrote:

This looks like a job for distributed ruby or DRb. You can use a drb
server that runs on a high port number and published a hash. Then in
your rails app you can access the hash just like a normal object and
store and lookup whatever you want in it. This way you can have one
process that handles your state data that is outside the rails app
and is persistent between requests.

This is truly interesting. Is any performance hit to be expected?

Juan-

I wouldn't expect there to be a noticeable performance hit. Rails

can use a DRb store for the sessions and it is one of the best
performing session containers, faster then ActiveRecord session
store. DRb is a very nice feature of ruby. I highly recommend playing
with it a bit and seeing what you can do with it.

I will probably be releasing my DrbRailsRunner plugin this weekend

after some more testing. This will allow you to publish your models
with a drb server. this can be used to share models between multiple
rails apps or to just offload a certain model instance with a
persistent state to drb thereby removing it from the rails request/
response cycle.

This will be awesome for kicking off long running tasks to the drb

server. So you could have a page make an ajax request for some action
that takes a while to run, then this action will hand over the job to
the drb server. The drb server will start the job and publish a
percent_complete variable. In your view that kicked off the long
running action you have a periodically call remote ajax request that
checks the percent_complete every few seconds and updates a progress
bar. Then when the percent_complete is 100% done you can ask Drb for
the results of the long running taks and display them or redirect
somewhere to display them or whatever. Cool thing is, you can have
any ruby code you want in the drb server. So it could be generating
huge PDF’s or running complex queries to get reports or using open-
uri to fetch the content of multiple other web pages and merging them
together. The possibilities are endless.

Cheers-
-Ezra Z.
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
removed_email_address@domain.invalid


#7

On Jun 1, 2006, at 2:31 PM, Andy T. wrote:


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

Hey Andy-

Yeah I did release it a week ago. It's called BackgrounDRb. It does

a lot more then what I was thinking back in January. You can get info
about it here:

http://brainspl.at/articles/2006/05/25/backgroundrb-new-release
http://brainspl.at/articles/2006/05/30/backgroundrb-gets-a-mailing-list
Mailing List: http://rubyforge.org/mailman/listinfo/backgroundrb-devel
rubyforge project: http://rubyforge.org/projects/backgroundrb/
README: http://backgroundrb.rubyforge.org

Cheers-
-Ezra


#8

Ezra Z. wrote:

On Jan 25, 2006, at 9:14 AM, Juan Lupi�n wrote:
I will probably be releasing my DrbRailsRunner plugin this weekend
after some more testing. This will allow you to publish your models
with a drb server. this can be used to share models between multiple

Ezra, did you ever release this?