At my day job this week we released an account manager app that lets people view/manage/pay their bills. It''s a C# .net app, I designed the interface (css, html, js), 10 others did the actual .net stuff (too many cooks that can''t boil water). It went live, and bad things started to happen. Customer 1 could see customer 2''s billing data, customer 2 would accidentally pay customer 3''s bill. It was all due to some "shared" variables getting overwritten when customers would do the same action at relatively the same time. My question is, is this something I should worry about with ROR/Ruby? and or caching? Thanks! -- Posted via http://www.ruby-forum.com/.
On 7/23/06, David C. <dave@pezians.com> wrote:> > At my day job this week we released an account manager app that lets > people view/manage/pay their bills. > > It''s a C# .net app, I designed the interface (css, html, js), 10 others > did the actual .net stuff (too many cooks that can''t boil water). > > It went live, and bad things started to happen. Customer 1 could see > customer 2''s billing data, customer 2 would accidentally pay customer > 3''s bill. It was all due to some "shared" variables getting overwritten > when customers would do the same action at relatively the same time. > > My question is, is this something I should worry about with ROR/Ruby? > and or caching? > > Thanks!If you''re sloppy, yes. Don''t be sloppy :) And really, this shouldn''t be an issue with C# either. -- Rick Olson http://techno-weenie.net
On 7/24/06, David C. <dave@pezians.com> wrote:> > > At my day job this week we released an account manager app that lets > people view/manage/pay their bills. > > It''s a C# .net app, I designed the interface (css, html, js), 10 others > did the actual .net stuff (too many cooks that can''t boil water). > > It went live, and bad things started to happen. Customer 1 could see > customer 2''s billing data, customer 2 would accidentally pay customer > 3''s bill. It was all due to some "shared" variables getting overwritten > when customers would do the same action at relatively the same time. > > My question is, is this something I should worry about with ROR/Ruby? > and or caching? > > Thanks! > > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/railsYes. When you cache you should use fragment cache. Include in the cache call a user id. the cache method accepts a hash like url for but it can be anything. You''re not restricted to real things (controllers/actions etc). If you don''t include somthing to seperate it by user, each user may get the same cached fragment. an eg might be <% cache( :controller => ''bill'', :action => ''show_last_10'', :user => current_user.id ) do -%> <%= all your cached frag -%> <% end %> This will scope the fragment to those parameters, and you can re-use it elsewhere if you want. Just include the same url in the cache. Be sure to expire the fragment if the data changes. expire_fragment( same_url_hash_used_in_cache_call ) Also the mean_time filter plugin is worth a look. with it you can put a scope call around a whole controller or parts of it. Hope this helps -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060724/db9d0f59/attachment.html
Daniel ----- wrote:> Hope this helpsThat does, thanks a bunch! Am half way through my first ROR app and haven''t quite gotten to caching yet. Since I''m the only one viewing the data at one time, just didn''t want to have a problem when I get ready for prod. And yes, I work with a group of hacks/drag-n-drop kings. Gotta love the corporate world. Thanks again. -- Posted via http://www.ruby-forum.com/.
Personally, I wouldn''t be caching anything until the app is done and tested. Then if you actually need caching go back and put it in where it''s really necessary, as determined by testing and benchmarking. With payment/billing systems especially be a bit conservative. Every additional feature you add is one more thing that can break in unexpected ways due to software upgrades, code changes, etc.. I also freeze a copy of rails and all the gems that I use in the vendor directory for apps like this. Ruby and rails is a fast moving target, and there is no way you can keep up with all the changes to rails, gems, plugins, etc.. Chris