On Fri, Apr 11, 2008 at 10:55 PM, Michael Koziarski <[EMAIL PROTECTED]> wrote: > > I'd suggest a candidate first-task is tidying up the ActiveRecord > allow_concurrency stuff to use a connection pool rather than blindly > establishing a connection per thread. This would require some pretty > heavy-duty refactorings in connection_specification, but it should be > reasonably straightforward. If anyone's interested in starting with > this, I'd be happy to collaborate and host a thread-safety branch on > my github account as a staging area before we include it for 'whatever > comes after 2.1'.
I don't know if I can start on it right away, but I'm very interested in helping with this. In particular, the establish_connection stuff and the way connections are cached is not very friendly right now to Java appservers where the connection pooling usually happens underneath the covers. If possible I'd like to find a solution that includes the possibility of opening and closing connections around each request and/or transaction. Opening connections in the appserver is cheap because it's just checking out/returning the connection to the pool. Perhaps any work toward that goal can use a similar abstraction -- then I can wholesale replace Rails' own connection pool with one that connects directly to the Java connection pool. Cheers, /Nick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
