Neither database is optimized (for better or for worse), and while we're
happy to see the open source alternative leading the closed source
behemoth, it's a bit unfair if the difference is to be found in
oci_adapter.rb.
Best guess is that the change is driven by the final approach for
handling reconnection on failure -- which proactively checks the
connection before every db access. Since the core OCI library doesn't
provide a way of checking status, this is being done by a select against
DUAL (in the OCI8AutoRecover#ping method).
Can you try modifying oci_adapter.rb, and change OCIAdapter#active? to
use @connection.active? instead of @connection.ping. The
OCI8AutoRecover#active? method doesn't hit the db at all, it just
returns the last known state. This will be faster, though it means
you'll actually get a db failure in your app before it reconnects.
In trunk this is line 222 of oci_adapter.rb.
If this corrects the performance issue, we can make this a configurable
options -- better performance w/ a hit on db failure, or worse
performance w/ better failure handling.
_______________________________________________
Rails-core mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails-core
