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 -- Posted via http://www.ruby-forum.com/.
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 On 1/25/06, Dustin <dsmit@mit.edu> 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? > > Thanks in advance for the help. > > -Dustin > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Jan 25, 2006, at 12:17 AM, 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? > > Thanks in advance for the help. > > -DustinDustin- 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 Zygmuntowicz Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 ezra@yakima-herald.com
> 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? -- ---------------------------------------------------- http://www.sobrerailes.com
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 Zygmuntowicz Yakima Herald-Republic WebMaster http://yakimaherald.com 509-577-7732 ezra@yakima-herald.com
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?-- Posted via http://www.ruby-forum.com/.
Ezra Zygmuntowicz 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 multipleEzra, did you ever release this? -- Posted via http://www.ruby-forum.com/.
On Jun 1, 2006, at 2:31 PM, Andy Trump wrote:> Ezra Zygmuntowicz 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? > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsHey 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060601/4ba9cff6/attachment-0001.html
Maybe Matching Threads
- Error after moving to production server
- Exception when doing DRb remote calls from a BackgrounDRb worker
- strange issue with backgroundrb behind apache/lighttpd
- DRb error when using rails_spec on OS X
- Connection to backgroundrb is lost when exiting action method