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 <[EMAIL PROTECTED]> 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
> [email protected]
> http://rubyforge.org/mailman/listinfo/camping-list
>
_______________________________________________
Camping-list mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/camping-list
