I am looking for a way to synchronize access to a shared data structure in a standard rails app. I read that if you are running on passenger, then Mutex.new is of no use? Can somebody please clarify this? I know that I can use transaction and :lock => true to do db level locking on models, but I have a global hash defined in an initializer as such GLOBAL_DATA = Hash.new and I am storing data in it that will be accessed by multiple clients... I would simply like to wrap access to this structure in some kind of synchronization. Anyone got any suggestions? thanks, Lee -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
On Jun 16, 10:05 am, cipher_neo <l33...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> I am looking for a way to synchronize access to a shared data > structure in a standard rails app. > > I read that if you are running on passenger, then Mutex.new is of no > use? Can somebody please clarify this? > > I know that I can use transaction and :lock => true to do db level > locking on models, but I have a global hash defined in an initializer > as such > > GLOBAL_DATA = Hash.new > > and I am storing data in it that will be accessed by multiple > clients... > > I would simply like to wrap access to this structure in some kind of > synchronization. > > Anyone got any suggestions?Um, how''s "don''t do this" work for you? Seriously - this is an amazingly bad idea, especially once you consider scaling past one application server. Is there a reason this data couldn''t just be stashed in the DB somehow? --Matt Jones -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
I think you are right, there is no particular reason why I could not put it in the db, except for the fact that it is data that should only live while the app is running. It need not be persistent across server restarts for instance On Jun 17, 3:02 pm, Matt Jones <al2o...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> On Jun 16, 10:05 am, cipher_neo <l33...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > I am looking for a way to synchronize access to a shared data > > structure in a standard rails app. > > > I read that if you are running on passenger, then Mutex.new is of no > > use? Can somebody please clarify this? > > > I know that I can use transaction and :lock => true to do db level > > locking on models, but I have a global hash defined in an initializer > > as such > > > GLOBAL_DATA = Hash.new > > > and I am storing data in it that will be accessed by multiple > > clients... > > > I would simply like to wrap access to this structure in some kind of > > synchronization. > > > Anyone got any suggestions? > > Um, how''s "don''t do this" work for you? Seriously - this is an > amazingly bad idea, especially once you consider scaling past one > application server. Is there a reason this data couldn''t just be > stashed in the DB somehow? > > --Matt Jones-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.