Hi!
I’ve kind of gotten desperate trying to figure out if there’s a safe/
good way to set the context for a class instance. I suppose if my
Rails application was running single threaded this wouldn’t be a
problem, but if I end up deploying it multi-threaded I could be for a
world of hurt.
I’m building a rails app that managed Member of a Group. There is a
Member model and a Group model. Since a Member can belong to many
Groups, and a Group can have many Member , there is a HABTM
association between them.
The question I’m having is determining the Group context in which a
Member instance exists. For example, to set a Member’s dues status as
“paid”, I need to know which Group the dues have been paid for. The
implementation should look something like this:
@member.paid=true
Without having to remember and set the Group everytime the Member’s
paid status is updated.
The test code I wrote sets the current_group class variable in Member
from the ApplicationController:
class ApplicationController < ActionController::Base
…
before_filter :set_current_group
def set_current_group
Member.current_group = current_group
end
…
end
This would assign the current_group variable to the Member. In the
Member model the current_group class attribute could be accessed and
reflect the correct Group from a Member object in a Controller or
View:
class Member < ActiveRecord::Base
cattr_accessor current_group
…
def paid=(status)
if (status)
@@current_group.paid_members << self
else
@@current_group.paid_member.delete(self)
end
end
def paid?
@@current_group.paid_members.include?(self)
end
…
end
In a Controller I could refer to the paid status from the added Member
method:
if @member.paid
Do something
end
For in a View I could loop through all Member and display which ones
have paid: (not a great example)
<% @members.each do |member| %>
<%= member.name %> payment status:
<% if member.paid %>Paid<% end %>
<% end %>
The concern is, after testing this out on WebBrick, a single threaded
runtime environment will maintain the Group context for the session,
but with a Multi-threaded runtime the Group context may be reset
between requests. I don’t want to run into an issue with different
user’s logging in and the paid status being nil or worse, seeing
someone else’s information.
Can someone please shed some light on this? I’m having a hard time
digging up good information on how the application context is shared
between request sessions. If I move to a multi-threaded environment,
the ApplicationController context for the last request and the new
thread request shouldn’t be shared.
Finally, I know that I can write the Member.paid() method to take a
Group, then return the paid status. It just seems really ugly to have
to carry the current_group round and manually pass it into the paid
method each time. I’m just trying to simplify the implementation of
paid(), while at the same time understand session context with Rails.
Thank you for anything anybody can provide!