On Thursday, October 3, 2013 5:06:23 PM UTC-7, GregD wrote: > Jeremy- > > I finally was able to back to these, plus an additional supported feature > for SQL Anywhere, LATERAL. >
Great! > > > > On Sep 14, 2013, at 3:17 AM, Jeremy Evans <[email protected]<javascript:>> > 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? > That's odd. Assuming the pool only had that single connection, disconnect will remove the connection, leaving the pool empty, so on the next query, Database#connect should be called to get a new connection. I'm not sure why that wouldn't be happening. > > > > >> #<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: > > There is no current spec for the transactional behavior I mentioned above. This spec just tests that the connection after disconnect is no longer valid. It's basically testing that disconnect_connection works correctly. It's a good proxy for seeing if the transactional behavior is likely to be incorrect, though. If you really want to test the transactional behavior, we could add a new spec, something like: specify "should have disconnect_connection result in a connection that is not usable" do begin @db.create_table!(:items){Integer :i} @db[:items].insert(1) @db.transaction do |c| @db.disconnect_connection(c) @db[:items].delete raise Sequel::Rollback end rescue # nil ensure @db.disconnect @db[:items].count.should == 1 if @db.table_exists?(:items) @db.drop_table?(:items) end end I'm not sure it's worth adding such a spec, though. It would be interesting to see the results of it with the native sqlanywhere adapter, though. 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.
