hello all. ive come to the point where im thinking about deploying my ''rails on rails'' app-development solution built in camping. mainly, im wondering what the barriers to thread-safety are. for db, i use redland, and afaik it spawns a single db connection for each find, and keeps a pool around to reuse. iow, no ActiveRecord. are class-vars a problem? theres one that i''d like to keep, a ''close'' cache of triples in a normal ruby Array.. read/writes to this are fast (much faster than HTML generation in markaby, from what i can tell), but i guess they would need to lock the other threads briefly. for simplicity. i''d prefer a single interpreter process. otherwise i''m going to have to come up with some distributed cache invalidation scheme (typically the user load is 1-15, small workgroups, which loadwise is fine except they may experience a few seconds lag in their requests if eg a heavy SPARQL query is going on in another request) oh, and id like to hear ''sure, but you have to hack up the mongrel configurator slightly, and not do this'' rather than ''just use a pack of mongrels'' cheers :)
carmen - I''m not sure _how_ much this will really help you, but I
recently explored a similar issue with an internal Camping app.
In summary, I needed to make sure that all calls to a specific
controller were always executed serially. i.e. - if two calls came in
at approximately the same time, the second call could not run until
the first one finished.
This was not a problem: I just included the ''thread'' library
and
wrapped the code in a synchronize block. The only requirement: I only
run a single mongrel instance.
Simple code example follows:
**********
require ''thread''
....
class Create < R ''/create''
def synchronize
mutex.synchronize {yield self}
end
def mutex
@mutex ||= Mutex.new
end
def get
synchronize do
# my code goes here...
end
end
end
******************
I hope this helps out some,
Michael Gorsuch
http://www.styledbits.com
On 3/12/07, carmen <_ at whats-your.name> wrote:> hello all. ive come to the point where im thinking about deploying my
''rails on rails'' app-development solution built in camping.
>
> mainly, im wondering what the barriers to thread-safety are.
>
> for db, i use redland, and afaik it spawns a single db connection for each
find, and keeps a pool around to reuse. iow, no ActiveRecord.
>
> are class-vars a problem? theres one that i''d like to keep, a
''close'' cache of triples in a normal ruby Array.. read/writes
to this are fast (much faster than HTML generation in markaby, from what i can
tell), but i guess they would need to lock the other threads briefly.
>
> for simplicity. i''d prefer a single interpreter process. otherwise
i''m going to have to come up with some distributed cache invalidation
scheme (typically the user load is 1-15, small workgroups, which loadwise is
fine except they may experience a few seconds lag in their requests if eg a
heavy SPARQL query is going on in another request)
>
> oh, and id like to hear ''sure, but you have to hack up the mongrel
configurator slightly, and not do this'' rather than ''just use
a pack of mongrels''
>
>
> cheers :)
> _______________________________________________
> Camping-list mailing list
> Camping-list at rubyforge.org
> http://rubyforge.org/mailman/listinfo/camping-list
>
On Wed Mar 14, 2007 at 08:14:36PM -0400, Michael Gorsuch wrote:> carmen - I''m not sure _how_ much this will really help you, but I > recently explored a similar issue with an internal Camping app. > > In summary, I needed to make sure that all calls to a specific > controller were always executed serially. i.e. - if two calls came in > at approximately the same time, the second call could not run until > the first one finished.thanks. ive got the PP thread chapter bookmarked, and planned to get into it. your example is nice and simple.. mainly i am unclear on what the current concurrency model is - its fairly obvious with rails since for whatever reason it''s more popular so theres tons of blogs discussing it, but i cant find anything except a CHANGELOG entry in 1.3 mentioning some method is thread-safe (but does this extend to the entire framework?) my brief experiments with subjective request timings using 2 browsers, along with stats from httperf, had me thinking everything is already serialized. and here youre suggesting the opposite... which is it!? i seem to recall a ''dangerous'' switch somewhere in mongrel or rails that disabled the explicit serialization. fwiw, heres my mongrel configurator: if __FILE__ == $0 Yard.create config = Mongrel::Configurator.new :host => (ARGV[0] || "0.0.0.0") do listener :port => (ARGV[1] || 80) do uri "/", :handler => Mongrel::Camping::CampingHandler.new(Camping::Reloader.new(__FILE__)) uri ''/s/'', :handler => Mongrel::DirHandler.new(File.dirname(__FILE__)+"/s") trap("INT") { stop }; run end end config.join end> > This was not a problem: I just included the ''thread'' library and
2007/3/15, Michael Gorsuch <michael.gorsuch at gmail.com>:> carmen - I''m not sure _how_ much this will really help you, but I > recently explored a similar issue with an internal Camping app. > > In summary, I needed to make sure that all calls to a specific > controller were always executed serially. i.e. - if two calls came in > at approximately the same time, the second call could not run until > the first one finished. > > This was not a problem: I just included the ''thread'' library and > wrapped the code in a synchronize block. The only requirement: I only > run a single mongrel instance. > > Simple code example follows: > > ********** > > require ''thread'' > .... > > class Create < R ''/create'' > def synchronize > mutex.synchronize {yield self} > end > > def mutex > @mutex ||= Mutex.new > end > > def get > synchronize do > # my code goes here... > end > end > end > > ****************** > > I hope this helps out some, > > Michael Gorsuch > http://www.styledbits.com > > > > On 3/12/07, carmen <_ at whats-your.name> wrote: > > hello all. ive come to the point where im thinking about deploying my ''rails on rails'' app-development solution built in camping. > > > > mainly, im wondering what the barriers to thread-safety are. > > > > for db, i use redland, and afaik it spawns a single db connection for each find, and keeps a pool around to reuse. iow, no ActiveRecord. > > > > are class-vars a problem? theres one that i''d like to keep, a ''close'' cache of triples in a normal ruby Array.. read/writes to this are fast (much faster than HTML generation in markaby, from what i can tell), but i guess they would need to lock the other threads briefly. > > > > for simplicity. i''d prefer a single interpreter process. otherwise i''m going to have to come up with some distributed cache invalidation scheme (typically the user load is 1-15, small workgroups, which loadwise is fine except they may experience a few seconds lag in their requests if eg a heavy SPARQL query is going on in another request) > > > > oh, and id like to hear ''sure, but you have to hack up the mongrel configurator slightly, and not do this'' rather than ''just use a pack of mongrels'' > > > > > > cheers :) > > _______________________________________________ > > Camping-list mailing list > > Camping-list at rubyforge.org > > http://rubyforge.org/mailman/listinfo/camping-list > > > _______________________________________________ > Camping-list mailing list > Camping-list at rubyforge.org > http://rubyforge.org/mailman/listinfo/camping-list >Are you sure it''s the right way to do ? It seems to me that an instance of the controller is created on each request. So with your approach, a mutex is created on each request and your don''t have the benefit of mutex locking. Adding an `at` before @mutex should do the trick. -- Cheers, zimbatm