Excellent!

This will be the biggest change,  we can do implicit checkout of a
connection when trying to access the database for the first time in a
thread, but implicit checkin seems to be asking for trouble.    We can
handle it for ActionController easily enough by checking the
connections back in after the request has been dispatched.

So my first thought is:

Foo.find(:first) # retrieves connection
Thread.new do
  Foo.find(:first) # retrieves another
  Bar.find(:first) # uses existing
  ActiveRecord::Base.release_connection
  Foo.find(:first) # retrieves another
end

With retrieving blocking until the connection is available.

There are two cases that I'm aware of that lead to those 'interesting' methods.

* Reloading in development mode (the classes get undefined, so the
connection is gone)
* re-establishing timed out connections.

By moving the connections to the pool rather than the classes that get
reloaded, we avoid the first problem.  Obviously checking out a
connection should imply that its been verified.

So with a proper 'pool' we can avoid all those methods, and improve
the code for the simple one-thread case too.

The code cleanup is pretty desperately needed,  it's some hokey nasty
stuff ;).  The dual benefit of getting jruby connection handling a
little easier is a definite win.

Rather than swapping in and out a different monitor, why not  have two
different connection handler classes, one of which returns and manages
a single connection, and another which manages a pool of a fixed size.
   The single connection version can expose the same API (checkout /
check in / release) and perhaps raise exceptions if accessed from
threads other than the one which created the connection.

new-connection-per-thread isn't a particularly great idea and I'd be
open to dropping it entirely.

Thanks for your work on this, it'll be good to tidy this up.

There are still a bunch of outstanding issues to be decided,
especially relating to objects retrieved in one thread and being
worked-on in another.  This messes up :lock=>true etc.  But let's tidy
up the code first, then decide what level on concurrent use we want to
support.

--
Cheers

Koz