On Friday, September 13, 2013 7:02:09 PM UTC-7, GregD wrote:
> Jeremy-
>
> I tried free the connection resources like the api gem said and that was
> no good. I got segment faults when the test executed the valid_connection?
> after the disconnect. So, that is not an option.
>
That's a shame.
I thought of adding to the app connection instance an attr_acccessor and
> method disconnected? when it is created. Then when I execute the sql, I
> could see if the conn has been disconnected? then throw/raise the
> exception. This did not work either, so I pp the objects to see what the
> heck was going on during a connect, disconnect and execute.
>
> Here is what is showed me:
>
> "connect: #<SQLAnywhere::a_sqlany_connection:0x914829c>"
> <-- ansi c connection object before extending it
> #<SQLAnywhere::a_sqlany_connection:0x914829c @disconnected=false>
> <-- same c object extended as it executes the sql
> "SQL: SELECT NULL"
> <-- sql to test the connection
> valid_connection? == true test
> "Pool: #<Sequel::ThreadedConnectionPool:0x8e8486c>"
> <-- Sequel pool object
> #<Sequel::ThreadedConnectionPool:0x8e8486c
> @after_connect=nil,
> @allocated=
> {#<Thread:0x8c61008 run>=>
> #<SQLAnywhere::a_sqlany_connection:0x914829c @disconnected=false>},
> @available_connections=[],
> @connection_handling=nil,
> @db=
> #<Sequel::SqlAnywhere::Database:
> "sqlanywhere://localhost?DBN=Test;UID=dba;PWD=sql">,
> @max_size=4,
> @mutex=#<Mutex:0x8e84858>,
> @sleep_time=0.001,
> @timeout=5.0>
> "Connection: #<SQLAnywhere::a_sqlany_connection:0x914829c>"
> "disconnected? false"
>
> "disconnect: #<SQLAnywhere::a_sqlany_connection:0x9f50b28>"
> <--- DB.disconnect start
> #<SQLAnywhere::a_sqlany_connection:0x9f50b28 @disconnected=false>
> "after disconnect: #<SQLAnywhere::a_sqlany_connection:0x9f50b28>"
> #<SQLAnywhere::a_sqlany_connection:0x9f50b28 @disconnected=true>
> <--- DB.disconnect end
>
> "connect: #<SQLAnywhere::a_sqlany_connection:0x9b7d758>"
> <-- DB.valid_connection? start - whoa conn object
> different. why?
>
DB.disconnect removes the connection from the pool after disconnecting. On
the next query, the pool is empty, so a new connection is created. This is
why the conn object is different.
> #<SQLAnywhere::a_sqlany_connection:0x9b7d758 @disconnected=false>
> "SQL: SELECT NULL"
> "Pool: #<Sequel::ThreadedConnectionPool:0x9c8ae70>"
> #<Sequel::ThreadedConnectionPool:0x9c8ae70
> @after_connect=nil,
> @allocated=
> {#<Thread:0x9a69038 run>=>
> #<SQLAnywhere::a_sqlany_connection:0x9b7d758 @disconnected=false>},
> @available_connections=[],
> @connection_handling=nil,
> @db=
> #<Sequel::SqlAnywhere::Database:
> "sqlanywhere://localhost?DBN=Test;UID=dba;PWD=sql">,
> @max_size=4,
> @mutex=#<Mutex:0x9c8ae5c>,
> @sleep_time=0.001,
> @timeout=5.0>
> "Connection: #<SQLAnywhere::a_sqlany_connection:0x9b7d758>"
> "disconnected? false"
> F
>
> Failures:
>
> 1) Sequel::Database should provide ability to check connections for
> validity
> Failure/Error: Unable to find matching line from backtrace
> expected: false value
> got: true
> # ./spec/integration/database_test.rb:99:in `block (2 levels) in <top
> (required)>'
>
> Finished in 0.33838 seconds
> 1 example, 1 failure
>
> Failed examples:
>
> rspec ./spec/integration/spec_helper.rb:77 # Sequel::Database should
> provide ability to check connections for validity
>
>
> I think I'm missing something very obvious or I need to override
> valid_connection?.
>
You should only need to override valid_connection? if there is a different
way to check if the connection is valid. Currently, Sequel issues a query
that should never raise an exception, and if it raises an exception, it
assumes the connection is not valid. Now, if SQLanywhere automatically
reconnects, I can see where that may not work and you would need to
override it. But that's only a bandaid over a gaping wound, since it
doesn't fix the underlying issue (implicit autoreconnection).
> But, how I'm I getting a totally different connection object/instance
> prior to executing the sql? Also, why is the pool object not contain any
> available connections? available_connections = []
>
available_connections is the connections that are currently available. If
the connection is currently checked out (by the current thread or another
thread), it will not be in available_connections, it will be in allocated.
> My goal is to get this as complete as possible. If this test is not
> possible, hopefully, you can except this as it being pending for the native
> adapter unless there is something really obvious that I'm missing.
>
If there is really no way to fix it, then yes, you probably want to mark
the spec as pending. Not having the ability to turn off implicit
autoreconnection means that the connection is broken as far as I am
concerned, at least for any situation where you are using transactions. I
would talk to upstream if possible and see if they are amenable to the
possibility of disabling it. Just give them the following example:
BEGIN;
# Disconnect happens here
DELETE FROM table_name;
ROLLBACK;
Implicit autoreconnection should result in this emptying table_name, since
the new connection doesn't know it is supposed to be inside a transaction.
Now, maybe their autoreconnection logic is smart enough to handle this
case correctly, but that's not something I'd trust unless I verified it
myself.
Thanks,
Jeremy
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/groups/opt_out.
