Jeremy- I finally was able to back to these, plus an additional supported feature for SQL Anywhere, LATERAL.
On Sep 14, 2013, at 3:17 AM, Jeremy Evans <[email protected]> wrote: > 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. It never went through my connect method again. So, did it dup the original connection object? > > #<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. Is there a way to test that or is there already a test for that? The failing database test is just: cspecify "should provide ability to check connections for validity", [:do, :postgres] do conn = @db.synchronize{|c| c} @db.valid_connection?(conn).should be_true @db.disconnect @db.valid_connection?(conn).should be_false end There is no transaction going on. The Sybase dbisql client states this, but I'n not sure the c ext gem sqlanywhere behaves the same: The DISCONNECT statement drops a connection with the database server and releases all resources used by it. If the connection to be dropped was named on the CONNECT statement, then the name can be specified. Specifying ALL drops all of the application’s connections to all database environments. CURRENT is the default and drops the current connection. An implicit ROLLBACK is executed on connections that are dropped. Thanks, -GregD -- 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.
