โ07-23-2019 10:53 AM
On a Windows Groundplex, we are using the โGeneric JDBC - Executeโ snaps to issue several different kinds of queries to a legacy Sybase Adaptive Server Anywhere 9 database. (Also sometimes called Sybase โSQL Server Anywhere.โ)
We are using the connection options recommended by Snaplogic in the online documentation. [TBD: put a link to that here.]
Every once in a while, a query that has previously worked just fine will โhangโ the connection. Once this has happened, attempts to query via that connection go unresolved and time out. We believe that when the problem happens, what may be happening is that the query is either failing or else not finishing in time, and that the connection is left open in an โoff hookโ state, with the result set still pending. Subsequent queries on such a channel wouldnโt get acknowledged because it would just be sitting there waiting for the previous action to completeโฆ which never does.
Has anyone else experienced this with a Sybase connection? (Or with any other non-standard legacy database connection?)
Any ideas how to troubleshoot and fix this?
โ07-29-2019 06:51 AM
Yeah, I think sybase made it the default on the idea that people would always have a write once mentality, where changes would have a reversing entry, or things would be only read. It is a nice concept, but I HATE that they made it the default. It gave me a lot of grief because the DBA insisted on doing ALL changes, and just wouldnโt listen. So that computer probably did over 2 months work for NOTHING. Luckily that was generally on the weekends, so it wanโt as bad as it could have been.
Outside of transactions, locks, and deadlocks, I think the database should be relatively fast, meaning that you wouldnโt notice a significant pause. And I am ASSUMING that that is what you mean. The page size at least WAS small, so it would do more page splits than say M/S SQL TODAY, or Oracle. So there might be more gaps where it seems to almost hesitate, but we are talking barely susceptible hesitations that may be tens or hundreds of milliseconds.
If you can, it might be a good idea to bring it up with sybase. It COULD be a jdbc problem, or even some oddity in sybase. If you are doing enough processing, it could even be garbage collection.
It could be a windows problem. Windows NEVER handled virtual memory well, and at least earlier versions of windows didnโt generally handle memory over a certain amount properly. They always wanted people to pay more to be able to do that. And what else is happening on that windows system?