I want to be able to set class attributes (in particular, ActiveResource::Base user, password, site, etc.) and for them to be isolated to a given request, both in terms of thread safety, and so that for the next request they are reset to defaults. For instance, if I set user and password, I want to make sure the user and password set for one user do not accidentally get used for a different user on a subsequent request. I could do this with a before_filter, but that seems like the wrong place to manage a model class'' instance variables. I''m not sure if the threading issue is really a problem, because I understand most rails servers are single threaded, but would it be a good idea to use Thread.current in class_attribute to provide thread safety? Secondly, what do you think of providing a way of resetting the value of class attributes between requests? Perhaps: class_attribute :x, :default => ''x will have this value at the beginning of every request'' or class_attribute :x class_initializer :set_x def self.set_x # this gets run at the beginning of every request self.x = ''Initial value'' end ActiveResource::Base.user doesn''t actually seem to be using class_attribute right now, but I assume it could be updated to do so. Please correct me if I have misunderstood the issues. Thanks, Nick -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
class_attribute works by creating a method on the class, and creating methods should be reliable. Additionally, class_attributes are used for configuration during boot, which is not a threadsafe environment. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickurban@gmail.com> wrote:> I want to be able to set class attributes (in particular, > ActiveResource::Base user, password, site, etc.) and for them to be > isolated to a given request, both in terms of thread safety, and so > that for the next request they are reset to defaults. For instance, if > I set user and password, I want to make sure the user and password set > for one user do not accidentally get used for a different user on a > subsequent request. I could do this with a before_filter, but that > seems like the wrong place to manage a model class'' instance > variables. > > I''m not sure if the threading issue is really a problem, because I > understand most rails servers are single threaded, but would it be a > good idea to use Thread.current in class_attribute to provide thread > safety? > > Secondly, what do you think of providing a way of resetting the value > of class attributes between requests? > > Perhaps: > > class_attribute :x, :default => ''x will have this value at the > beginning of every request'' > > or > > class_attribute :x > class_initializer :set_x > def self.set_x > # this gets run at the beginning of every request > self.x = ''Initial value'' > end > > ActiveResource::Base.user doesn''t actually seem to be using > class_attribute right now, but I assume it could be updated to do so. > > Please correct me if I have misunderstood the issues. > > Thanks, > > Nick > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
My concern is that I don''t want one thread to change the user and password, and suddenly another thread has the wrong credentials set. Is that a non-issue? Any comment on resetting the value at the beginning of a request? Thanks, Nick On Nov 14, 3:31 pm, Yehuda Katz <wyc...@gmail.com> wrote:> class_attribute works by creating a method on the class, and creating > methods should be reliable. > > Additionally, class_attributes are used for configuration during boot, > which is not a threadsafe environment. > > Yehuda Katz > (ph) 718.877.1325 > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickur...@gmail.com> wrote: > > I want to be able to set class attributes (in particular, > > ActiveResource::Base user, password, site, etc.) and for them to be > > isolated to a given request, both in terms of thread safety, and so > > that for the next request they are reset to defaults. For instance, if > > I set user and password, I want to make sure the user and password set > > for one user do not accidentally get used for a different user on a > > subsequent request. I could do this with a before_filter, but that > > seems like the wrong place to manage a model class'' instance > > variables. > > > I''m not sure if the threading issue is really a problem, because I > > understand most rails servers are single threaded, but would it be a > > good idea to use Thread.current in class_attribute to provide thread > > safety? > > > Secondly, what do you think of providing a way of resetting the value > > of class attributes between requests? > > > Perhaps: > > > class_attribute :x, :default => ''x will have this value at the > > beginning of every request'' > > > or > > > class_attribute :x > > class_initializer :set_x > > def self.set_x > > # this gets run at the beginning of every request > > self.x = ''Initial value'' > > end > > > ActiveResource::Base.user doesn''t actually seem to be using > > class_attribute right now, but I assume it could be updated to do so. > > > Please correct me if I have misunderstood the issues. > > > Thanks, > > > Nick > > > -- > > You received this message because you are subscribed to the Google Groups > > "Ruby on Rails: Core" group. > > To post to this group, send email to rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscribe@googlegroups.com. > > For more options, visit this group at > >http://groups.google.com/group/rubyonrails-core?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Michael Koziarski
2011-Nov-14 19:46 UTC
Re: Re: class_attribute thread safety and default value
On Tuesday, 15 November 2011 at 8:06 AM, Nick Urban wrote:> My concern is that I don''t want one thread to change the user and > password, and suddenly another thread has the wrong credentials set. > Is that a non-issue? >It''s a real issue, using class_attribute is *not* suitable for things which are changed by multiple threads.> > Any comment on resetting the value at the beginning of a request? >To me it seems that this is only needed because the particular value you''re changing shouldn''t be a class_attribute. Class attributes are great simple solution for things like "what''s the asset path" or "where is the temp directory", but they''re really just glorified global variables. If you''re flipping them every request then I''d suggest we should fix the particular value to be something thread local or to have a completely different API rather than try to put a band-aid on the whole notion of class attributes. -- Cheers, Koz> > On Nov 14, 3:31 pm, Yehuda Katz <wyc...@gmail.com (http://gmail.com)> wrote: > > class_attribute works by creating a method on the class, and creating > > methods should be reliable. > > > > Additionally, class_attributes are used for configuration during boot, > > which is not a threadsafe environment. > > > > Yehuda Katz > > (ph) 718.877.1325 > > > > > > > > > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickur...@gmail.com (http://gmail.com)> wrote: > > > I want to be able to set class attributes (in particular, > > > ActiveResource::Base user, password, site, etc.) and for them to be > > > isolated to a given request, both in terms of thread safety, and so > > > that for the next request they are reset to defaults. For instance, if > > > I set user and password, I want to make sure the user and password set > > > for one user do not accidentally get used for a different user on a > > > subsequent request. I could do this with a before_filter, but that > > > seems like the wrong place to manage a model class'' instance > > > variables. > > > > > > > > > > I''m not sure if the threading issue is really a problem, because I > > > understand most rails servers are single threaded, but would it be a > > > good idea to use Thread.current in class_attribute to provide thread > > > safety? > > > > > > > > > > Secondly, what do you think of providing a way of resetting the value > > > of class attributes between requests? > > > > > > > > > > Perhaps: > > > > > class_attribute :x, :default => ''x will have this value at the > > > beginning of every request'' > > > > > > > > > > or > > > > > class_attribute :x > > > class_initializer :set_x > > > def self.set_x > > > # this gets run at the beginning of every request > > > self.x = ''Initial value'' > > > end > > > > > > > > > > ActiveResource::Base.user doesn''t actually seem to be using > > > class_attribute right now, but I assume it could be updated to do so. > > > > > > > > > > Please correct me if I have misunderstood the issues. > > > > > Thanks, > > > > > Nick > > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Ruby on Rails: Core" group. > > > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > > To unsubscribe from this group, send email to > > > rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > > > For more options, visit this group at > > > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > > > > > > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Agreed. Class attributes have similar threading semantics to class variables, with the improvement that they inherit properly. Yehuda Katz (ph) 718.877.1325 On Mon, Nov 14, 2011 at 11:46 AM, Michael Koziarski <michael@koziarski.com>wrote:> > > On Tuesday, 15 November 2011 at 8:06 AM, Nick Urban wrote: > > My concern is that I don''t want one thread to change the user and > password, and suddenly another thread has the wrong credentials set. > Is that a non-issue? > > It''s a real issue, using class_attribute is *not* suitable for things > which are changed by multiple threads. > > > Any comment on resetting the value at the beginning of a request? > > To me it seems that this is only needed because the particular value > you''re changing shouldn''t be a class_attribute. Class attributes are great > simple solution for things like "what''s the asset path" or "where is the > temp directory", but they''re really just glorified global variables. If > you''re flipping them every request then I''d suggest we should fix the > particular value to be something thread local or to have a completely > different API rather than try to put a band-aid on the whole notion of > class attributes. > > -- > Cheers, > > Koz > > > > On Nov 14, 3:31 pm, Yehuda Katz <wyc...@gmail.com> wrote: > > class_attribute works by creating a method on the class, and creating > methods should be reliable. > > Additionally, class_attributes are used for configuration during boot, > which is not a threadsafe environment. > > Yehuda Katz > (ph) 718.877.1325 > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickur...@gmail.com> wrote: > > I want to be able to set class attributes (in particular, > ActiveResource::Base user, password, site, etc.) and for them to be > isolated to a given request, both in terms of thread safety, and so > that for the next request they are reset to defaults. For instance, if > I set user and password, I want to make sure the user and password set > for one user do not accidentally get used for a different user on a > subsequent request. I could do this with a before_filter, but that > seems like the wrong place to manage a model class'' instance > variables. > > > I''m not sure if the threading issue is really a problem, because I > understand most rails servers are single threaded, but would it be a > good idea to use Thread.current in class_attribute to provide thread > safety? > > > Secondly, what do you think of providing a way of resetting the value > of class attributes between requests? > > > Perhaps: > > > class_attribute :x, :default => ''x will have this value at the > beginning of every request'' > > > or > > > class_attribute :x > class_initializer :set_x > def self.set_x > # this gets run at the beginning of every request > self.x = ''Initial value'' > end > > > ActiveResource::Base.user doesn''t actually seem to be using > class_attribute right now, but I assume it could be updated to do so. > > > Please correct me if I have misunderstood the issues. > > > Thanks, > > > Nick > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Koz, thanks for the explanation. The possibility that class attributes are the wrong solution had occurred to me, but that is the way things are currently done in ActiveResource. A possible API change which avoids having to pass the values to every AR call (pretty awkward) would be to instantiate an object which holds the configuration data: @configured_resource = Resource.configure do |r| r.user = ''user'' r.password = ''pass'' end @configured_resource.find(1) # passes user and password That seems like a better design, even though it wouldn''t match the ActiveRecord syntax. Thoughts? Nick On Mon, Nov 14, 2011 at 4:46 PM, Michael Koziarski <michael@koziarski.com>wrote:> > > On Tuesday, 15 November 2011 at 8:06 AM, Nick Urban wrote: > > My concern is that I don''t want one thread to change the user and > password, and suddenly another thread has the wrong credentials set. > Is that a non-issue? > > It''s a real issue, using class_attribute is *not* suitable for things > which are changed by multiple threads. > > > Any comment on resetting the value at the beginning of a request? > > To me it seems that this is only needed because the particular value > you''re changing shouldn''t be a class_attribute. Class attributes are great > simple solution for things like "what''s the asset path" or "where is the > temp directory", but they''re really just glorified global variables. If > you''re flipping them every request then I''d suggest we should fix the > particular value to be something thread local or to have a completely > different API rather than try to put a band-aid on the whole notion of > class attributes. > > -- > Cheers, > > Koz > > > > On Nov 14, 3:31 pm, Yehuda Katz <wyc...@gmail.com> wrote: > > class_attribute works by creating a method on the class, and creating > methods should be reliable. > > Additionally, class_attributes are used for configuration during boot, > which is not a threadsafe environment. > > Yehuda Katz > (ph) 718.877.1325 > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickur...@gmail.com> wrote: > > I want to be able to set class attributes (in particular, > ActiveResource::Base user, password, site, etc.) and for them to be > isolated to a given request, both in terms of thread safety, and so > that for the next request they are reset to defaults. For instance, if > I set user and password, I want to make sure the user and password set > for one user do not accidentally get used for a different user on a > subsequent request. I could do this with a before_filter, but that > seems like the wrong place to manage a model class'' instance > variables. > > > I''m not sure if the threading issue is really a problem, because I > understand most rails servers are single threaded, but would it be a > good idea to use Thread.current in class_attribute to provide thread > safety? > > > Secondly, what do you think of providing a way of resetting the value > of class attributes between requests? > > > Perhaps: > > > class_attribute :x, :default => ''x will have this value at the > beginning of every request'' > > > or > > > class_attribute :x > class_initializer :set_x > def self.set_x > # this gets run at the beginning of every request > self.x = ''Initial value'' > end > > > ActiveResource::Base.user doesn''t actually seem to be using > class_attribute right now, but I assume it could be updated to do so. > > > Please correct me if I have misunderstood the issues. > > > Thanks, > > > Nick > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
A shortcoming of this solution is that you''d have to perform the configuration for all active resource classes that you''re using, which would significantly reduce its ''dryness''. Given the current ARes design, having an inheritable configuration is very valuable. Perhaps a better solution would be to create a threadsafe, resettable class-attribute-like structure which could be mixed into ActiveResource::Base? On Mon, Nov 14, 2011 at 5:20 PM, Nick Urban <nickurban@gmail.com> wrote:> Koz, thanks for the explanation. > > The possibility that class attributes are the wrong solution had occurred > to me, but that is the way things are currently done in ActiveResource. > > A possible API change which avoids having to pass the values to every AR > call (pretty awkward) would be to instantiate an object which holds the > configuration data: > > @configured_resource = Resource.configure do |r| > r.user = ''user'' > r.password = ''pass'' > end > > @configured_resource.find(1) # passes user and password > > That seems like a better design, even though it wouldn''t match the > ActiveRecord syntax. > > Thoughts? > > Nick > > On Mon, Nov 14, 2011 at 4:46 PM, Michael Koziarski <michael@koziarski.com>wrote: > >> >> >> On Tuesday, 15 November 2011 at 8:06 AM, Nick Urban wrote: >> >> My concern is that I don''t want one thread to change the user and >> password, and suddenly another thread has the wrong credentials set. >> Is that a non-issue? >> >> It''s a real issue, using class_attribute is *not* suitable for things >> which are changed by multiple threads. >> >> >> Any comment on resetting the value at the beginning of a request? >> >> To me it seems that this is only needed because the particular value >> you''re changing shouldn''t be a class_attribute. Class attributes are great >> simple solution for things like "what''s the asset path" or "where is the >> temp directory", but they''re really just glorified global variables. If >> you''re flipping them every request then I''d suggest we should fix the >> particular value to be something thread local or to have a completely >> different API rather than try to put a band-aid on the whole notion of >> class attributes. >> >> -- >> Cheers, >> >> Koz >> >> >> >> On Nov 14, 3:31 pm, Yehuda Katz <wyc...@gmail.com> wrote: >> >> class_attribute works by creating a method on the class, and creating >> methods should be reliable. >> >> Additionally, class_attributes are used for configuration during boot, >> which is not a threadsafe environment. >> >> Yehuda Katz >> (ph) 718.877.1325 >> >> >> >> >> >> >> >> On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickur...@gmail.com> wrote: >> >> I want to be able to set class attributes (in particular, >> ActiveResource::Base user, password, site, etc.) and for them to be >> isolated to a given request, both in terms of thread safety, and so >> that for the next request they are reset to defaults. For instance, if >> I set user and password, I want to make sure the user and password set >> for one user do not accidentally get used for a different user on a >> subsequent request. I could do this with a before_filter, but that >> seems like the wrong place to manage a model class'' instance >> variables. >> >> >> I''m not sure if the threading issue is really a problem, because I >> understand most rails servers are single threaded, but would it be a >> good idea to use Thread.current in class_attribute to provide thread >> safety? >> >> >> Secondly, what do you think of providing a way of resetting the value >> of class attributes between requests? >> >> >> Perhaps: >> >> >> class_attribute :x, :default => ''x will have this value at the >> beginning of every request'' >> >> >> or >> >> >> class_attribute :x >> class_initializer :set_x >> def self.set_x >> # this gets run at the beginning of every request >> self.x = ''Initial value'' >> end >> >> >> ActiveResource::Base.user doesn''t actually seem to be using >> class_attribute right now, but I assume it could be updated to do so. >> >> >> Please correct me if I have misunderstood the issues. >> >> >> Thanks, >> >> >> Nick >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To post to this group, send email to rubyonrails-core@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > >-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Michael Koziarski
2011-Nov-14 22:41 UTC
Re: Re: class_attribute thread safety and default value
On Tuesday, 15 November 2011 at 11:23 AM, Nick Urban wrote:> A shortcoming of this solution is that you''d have to perform the configuration for all active resource classes that you''re using, which would significantly reduce its ''dryness''. Given the current ARes design, having an inheritable configuration is very valuable. Perhaps a better solution would be to create a threadsafe, resettable class-attribute-like structure which could be mixed into ActiveResource::Base? >The current design is, basically, just not really intended for the use case you have in mind. So there are two options, either completely rework ActiveResource''s api such that it *does* work in this way, or accept its limitations and use one of the dozens of other http client libraries. I''ve had several clients who use ActiveResource as a nice simple integration API to tie one app to another, but others who had a more complicated authentication or connection management requirement. Those clients use other libraries and I don''t think there''s anything horribly wrong with that. -- Cheers, Koz> > > On Mon, Nov 14, 2011 at 5:20 PM, Nick Urban <nickurban@gmail.com (mailto:nickurban@gmail.com)> wrote: > > Koz, thanks for the explanation. > > > > The possibility that class attributes are the wrong solution had occurred to me, but that is the way things are currently done in ActiveResource. > > > > A possible API change which avoids having to pass the values to every AR call (pretty awkward) would be to instantiate an object which holds the configuration data: > > > > @configured_resource = Resource.configure do |r| > > r.user = ''user'' > > r.password = ''pass'' > > end > > > > @configured_resource.find(1) # passes user and password > > > > That seems like a better design, even though it wouldn''t match the ActiveRecord syntax. > > > > Thoughts? > > > > Nick > > > > On Mon, Nov 14, 2011 at 4:46 PM, Michael Koziarski <michael@koziarski.com (mailto:michael@koziarski.com)> wrote: > > > > > > > > > > > > On Tuesday, 15 November 2011 at 8:06 AM, Nick Urban wrote: > > > > > > > My concern is that I don''t want one thread to change the user and > > > > password, and suddenly another thread has the wrong credentials set. > > > > Is that a non-issue? > > > > > > > It''s a real issue, using class_attribute is *not* suitable for things which are changed by multiple threads. > > > > > > > Any comment on resetting the value at the beginning of a request? > > > > > > > To me it seems that this is only needed because the particular value you''re changing shouldn''t be a class_attribute. Class attributes are great simple solution for things like "what''s the asset path" or "where is the temp directory", but they''re really just glorified global variables. If you''re flipping them every request then I''d suggest we should fix the particular value to be something thread local or to have a completely different API rather than try to put a band-aid on the whole notion of class attributes. > > > > > > -- > > > Cheers, > > > > > > Koz > > > > > > > > > > On Nov 14, 3:31 pm, Yehuda Katz <wyc...@gmail.com (http://gmail.com)> wrote: > > > > > class_attribute works by creating a method on the class, and creating > > > > > methods should be reliable. > > > > > > > > > > Additionally, class_attributes are used for configuration during boot, > > > > > which is not a threadsafe environment. > > > > > > > > > > Yehuda Katz > > > > > (ph) 718.877.1325 (tel:718.877.1325) > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Nov 14, 2011 at 10:19 AM, Nick Urban <nickur...@gmail.com (http://gmail.com)> wrote: > > > > > > I want to be able to set class attributes (in particular, > > > > > > ActiveResource::Base user, password, site, etc.) and for them to be > > > > > > isolated to a given request, both in terms of thread safety, and so > > > > > > that for the next request they are reset to defaults. For instance, if > > > > > > I set user and password, I want to make sure the user and password set > > > > > > for one user do not accidentally get used for a different user on a > > > > > > subsequent request. I could do this with a before_filter, but that > > > > > > seems like the wrong place to manage a model class'' instance > > > > > > variables. > > > > > > > > > > > > > > > > > > > > > > I''m not sure if the threading issue is really a problem, because I > > > > > > understand most rails servers are single threaded, but would it be a > > > > > > good idea to use Thread.current in class_attribute to provide thread > > > > > > safety? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Secondly, what do you think of providing a way of resetting the value > > > > > > of class attributes between requests? > > > > > > > > > > > > > > > > > > > > > > Perhaps: > > > > > > > > > > > class_attribute :x, :default => ''x will have this value at the > > > > > > beginning of every request'' > > > > > > > > > > > > > > > > > > > > > > or > > > > > > > > > > > class_attribute :x > > > > > > class_initializer :set_x > > > > > > def self.set_x > > > > > > # this gets run at the beginning of every request > > > > > > self.x = ''Initial value'' > > > > > > end > > > > > > > > > > > > > > > > > > > > > > ActiveResource::Base.user doesn''t actually seem to be using > > > > > > class_attribute right now, but I assume it could be updated to do so. > > > > > > > > > > > > > > > > > > > > > > Please correct me if I have misunderstood the issues. > > > > > > > > > > > Thanks, > > > > > > > > > > > Nick > > > > > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google Groups > > > > > > "Ruby on Rails: Core" group. > > > > > > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > > > > > To unsubscribe from this group, send email to > > > > > > rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > > > > > > For more options, visit this group at > > > > > > http://groups.google.com/group/rubyonrails-core?hl=en. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > > > > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > > > > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > > > > > > > > > > > > > > > > > > > > > -- > > > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > > > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com). > > > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.