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.
I'm not sure why the flag is true when webrick boots, so that needs to
be investigated.
A second line of attack is the allows_concurrency flag itself. I
can't think when you'd ever want it to be false. 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?
Tom Ward
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
