Tom Ward wrote:
On 2/28/06, Michael Schoen <[EMAIL PROTECTED]> wrote:
I can reproduce this problem with my (very) basic toy application.
Running Windows XP/Webrick/SQL Server. I'll see if I can locate the
cause..
Ditto. I run into the same issue under Debian/Lighttpd/SCGI/Oracle.
I've narrowed it down to the allow_concurrency flag.
When starting webrick in development mode, on the first call to
ActiveRecord::Base.connection_cache, allow_concurrency is true, whilst
for subsequent calls it is false. The first call (with
allow_concurrency = true) creates a hash {<thread_id> => {}} but just
returns an empty hash. Subsequent calls (with allow_concurrency =
false) returns the entire hash (including the thread_id bit) which
verify_connections! can't cope with.
Nice sleuthing. The problem is caused by the line
ActiveRecord::Base.threaded_connections = false
in webrick_server.rb
It shouldn' be there, IMO.
Comment out the line, and your app will fly again.
I'm not sure why the flag is true when webrick boots, so that needs to
be investigated.
True is the default for ActiveRecord, for historical reasons.
A second line of attack is the allows_concurrency flag itself. I
can't think when you'd ever want it to be false.
FCGI is single threaded. By having the flag, we can optimize AR for
single threaded apps.
I can't see the harm
in having concurrency support, even in single-threaded applications.
All turning it off allows you, is to share the same connection across
multiple threads, but as provided, this wouldn't be thread-safe in any
case. Assuming allow_concurrency is always true fixes this issue, but
there may be applications I haven't thought of that will be adversely
affected. Thoughts?
-- stefan
--
For rails performance tuning, see: http://railsexpress.de/blog
Subscription: http://railsexpress.de/blog/xml/rss20/feed.xml
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
