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