I haven't been able to figure out the reasoning behind the mutex lock
on controller actions.
The README says:
"Merb does have a mutex lock around the call to your controller's
action anywhere that you can call AR objects. Merb's lock is way
smaller then rails giant lock though and allows for many more
concurrent requests to be handled by one process."
But ActiveRecord says it's thread safe, if it's configured with
ActiveRecord::Base.allow_concurrency = true.
Is there a reason that this isn't implemented in Merb that I have not
been able to discover? Turning on AR concurrency and removing the
mutex lock I feel would improve performance quite a bit. I can whip up
some patches to enable this if it's a good idea, but I have an
impression that nobody has done this yet for a reason.
Thanks,
-Kyle
PS: We're doing a Merb session at Minnebar, all are invited!
http://barcamp.org/MinneBarSessions#Merb
Yes the reason is that ActiveRecord lies about being thread safe. Not
only does it perform worse in thread safe 'mode' but it sometimes
leaks data across threads, returning the wrong result set to a
different request!
Also AR uses one db connection *per thread* and does not clean up
after itself so unless you do manual connection cleanups you will
quickly exhaust all of your db connections.
In general stay very far away from
ActiveRecord::Base.allow_concurrency = true
Cheers-
- Ezra Zygmuntowicz
-- Founder & Software Architect
-- ez...@engineyard.com
-- EngineYard.com
So, does AR not do a lock when allow_concurrency is set to false? Is
that why the action mutex lock is in place?
Thanks,
-Kyle
AR does no locking when allow_concurrency is false, it just assumes
that only one thread will ever be running at one time when AR is
invoked. You can easily turn the mutex in merb off:
$ merb -X off