I have read Arun G.'s
bloghttp://weblogs.java.net/blog/arungupta/archive/2007/09/totd_9_using_jd.html
on using jruby/rails with a glassfish database connection pool and I
have
been able to set this up. I have a question regarding this though that
I’m
sure someone has encountered. Doesn’t rails use persistent connections,
which would prevent them from being returned to the pool?
I am concerned (and some simple tests seem to bear this out) that
setting up
a deployment that handles multiple simultaneous users will saturate the
connection pool and some of the threads will never get a connection.
If this is the case, can I configure rails to not use persistent
connections, or can I use an idle timeout setting on glassfish to
reclaim
idle connections?
Nice find - had seen the presentation before but didn’t realise
JRuby-Rack bundled the connection pool hack; shouldn’t that mean
there’s no need to do anything for Rails bundled with Warbler to ‘just
work’?
I have read Arun G.'s blog on using jruby/rails with a glassfish
database connection pool and I have been able to set this up. I have a
question regarding this though that I’m sure someone has encountered.
Doesn’t rails use persistent connections, which would prevent them from
being returned to the pool?
Dick, just FYI, JRuby-Rack doesn’t bundle the connection pool hack –
I thought it was a little dangerous to assume that you’re always
running with a connection pool. So you’ll still have to apply it
yourself.
The “hack” really needs to be applied to ActiveRecord-JDBC, but I
don’t have a foolproof way of detecting that you’re using a connection
pool. More likely is that I’ll modify AR-JDBC to work with Rails 2.2’s
connection pooling.
Dick, just FYI, JRuby-Rack doesn’t bundle the connection pool hack –
I thought it was a little dangerous to assume that you’re always
running with a connection pool. So you’ll still have to apply it
yourself.