On Dec 2, 9:09 am, Drunkguy <[EMAIL PROTECTED]> wrote:
> There is an older oracle database that I make a connection to, but the
> connection isn't stable and it just goes away after a period of time.
> I need to be able to try to catch that and reconnect if it has gone
> away.
>
> While inspecting the object that Sequel.connect makes, I see that
> there is a test_connection method, but that returns true even after I
> see I lost the connection. Below is some snips from irb, I did cut
> out a lot of the stack trace.
>
> irb(main):014:0> DB = Sequel.connect('oracle://
> test:[EMAIL PROTECTED]:1521/DB')
>
> irb(main):015:0> rows = DB[:reporter_status].filter(:firstoccurrence
> => "28-NOV-08")
> => #<Sequel::Oracle::Dataset: "SELECT * FROM \"REPORTER_STATUS\" WHERE
> (\"FIRSTOCCURRENCE\" = '28-NOV-08')">
>
> irb(main):016:0> rows.count
> OCIError: ORA-03114: not connected to ORACLE
> from stmt.c:539:in oci8lib.so
>
> irb(main):017:0> DB.test_connection
> => true
>
> irb(main):018:0> DB.disconnect
> OCIError: ORA-03114: not connected to ORACLE
> from svcctx.c:144:in oci8lib.so
>
> You can see that after I try to do rows.count, that test_connection is
> returning true. Are there parameters I need to pass to it? Should I
> be testing the connection another way?
test_connection only tests that a connection can be acquired, it
doesn't test that already acquired connections are all valid (which
would generally require using them for something, which is probably
database dependent, and test_connection is generic). Some adapters
try to detect disconnects and reconnect automatically (e.g.
postgres). I'm personally a little concerned by this approach, as I'm
not sure that given the right circumstances it won't attempt to send
the same SQL to the server twice.
The proper way to handle this would be to have the adapters raise a
specific subclass of Sequel::DatabaseError when a database disconnect
is detected, so that the connection pool code could rescue that error
subclass and remove that connection from the connection pool and
reraise the error (which the app can handle just like any other
DatabaseError). This requires a small change to the connection pool
code as well as changes to adapters. I think I'll give a shot at
converting the built in reconnect support in the postgres adapter to
this, and if that works, the approach can be expanded to the other
adapters as other people decide to add support to them.
Jeremy
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sequel-talk" 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/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---
