We have a customer who started using our pb9/sqla10 product with go-global,
a pb-to-the-web citrix work-alike. So, with go-global, we have multiple pb9
sessions of our app accessing a sqla10 server on another box thru ODBC.
Occasionally, users will experience a situation where the app will freeze
and then report a lost data connection. Once the data base disconnect is
reported, the user has to leave the app and return, to continue working.

I was wondering if the odbc driver might be causing a problem in this
multi-session server.
Might multiple instances of the odbc driver cause a problem?
Any ideas/thoughts/suggestions welcome.

Thanks,
Doug
p.s. Also, does anyone know how the "Start Database Automatically" and
"Stop Database After Last Disconnect" fields should be set at this customer
site? I think by default, they are checked.

I don't know how any ODBC driver (alone) could cause
such a problem. I don't know the go-global product but
I have no reason to believe there is a sharing of (in-process)
DLLs or memory across 'virtual machine' sessions, and thus
there should be no interaction on the go-glob. server.

On the other hand, multiple instances of the application (each
loading the driver manager gear and the driver) will require a
lot of memory and that could cause a lot of thrashing to the
PagingFile if your OS and hardware has limited RAM.

PB itself is not (traditionally) a lean client. The datawindow
gear can comsue a lot of RAM and so that may just be
adding up quicker than the platform can keep up with.

Otherwise....

Such random/abnormal disconnects may be caused by
a number of factors and those may need a deeper
analysis. I suspect this may have something to do
with the nature of the network connectivity between
the go-glob. server host and the database server but
that would be a guess.

Other than possible network glitches, about the only thing that
has really changed here is the numbers of things and where they
are operating. On the g-g server's host you are running many
pb applications, whereas without g-g you would typically just
run one such client. Given this hosting (assumidly internet
accessed) you may be running many more instance than what
your typical customer base may do (on a single machine) and
that may be translating into many more active and/or idle database
connections in the case of this one customer's usage. It is entirely
possible the hardware and OS on either of the two server machines
may be swamped in some fashion and may end up underservicing
the network. You will also want to understand the available resources
and if each such guest application has sufficient.

Also since your actual clients are dependent upon the GUI
activity and that too is stretched across a different network link
(via the g-g client), you may find the timing of actions at that
level have been delayed or elongated in a way which may be
causing the client servicing of the database connections are
having some sort of timing impact.

Both factors together represent double the number of sockets
in use by the g-g host machine. That could easilty translate into
saturated network stacks, adapters and CPUs and that could
have the effect of causing network timeouts.

One thing you may want to focus on is the timing of the effect.
If only one such guest app. fails randomly and there is no grouping
of those, this could be from a completely different cause than if
multiple fail at the same time. I would also look for possible
general slowness across all sessions just before/during the failures.

I would monitor the two host machine (g-g and db) using the
performance monitors on each looking for network errors,
virtual memory stats, etc. You could also add the -z switch
to the server to maybe get a little more detail that way.

HTH


"Doug Stone" <doug.stone (AT) res-q (DOT) com> wrote

Nick, thanks for that feedback.
I will try working up a protocol for monitoring the server.
In the meantime, I had an odbc trace running when I experienced the app
freezing.
Do you see anything interesting in the trace log below?

Thanks again,
Doug

Wed Nov 25 2009 07:25:59
07:25:59 Attempting to connect using:
UID=dba;PWD=********;DBN=resqdb;ENG=resqsrvr2k;CON =SQL_DBC_2874848;ASTOP=NO;INT=NO;DBG=YES;LOG=d:\re sq\odbc_log.txt;DMRF=NO;LINKS='TCPIP{host=mpresq01 ;port=2638}';COMP=NO
07:25:59 Attempting to connect to a running server...
07:25:59 Trying to start TCPIP link ...

07:25:59 TCP using Winsock version 2.2
07:26:00 My IP address is 10.11.67.67
07:26:00 My IP address is 127.0.0.1
07:26:00 TCPIP link started successfully

07:26:00 Attempting TCPIP connection (address 10.8.160.102:2638 found in
sasrv.ini cache)

07:26:00 Trying to find server at cached address 10.8.160.102:2638 without
broadcasting
07:26:00 Found server, verifying server name
07:26:00 Found database server at address 10.8.160.102
07:26:00 Found database server resqsrvr2k on TCPIP link
07:26:00 Connected using client address 10.11.67.67:3099
07:26:00 Connected to server over TCPIP at address 10.8.160.102:2638

07:26:00 Connected to SQL Anywhere Server version 10.0.1.3415
07:26:00 Application information:
07:26:00 IP=10.11.67.67;HOST=PARESQ01;OS='Windows 2003 Build 3790 Service
Pack
2';PID=0x14c0;THREAD=0x154c;EXE=D:\resq\resqwin\re sqprod\resq_lrm.exe;VERSION=10.0.1.3415;API=ODBC;T IMEZONEADJUSTMENT=-480
07:26:00 Connected to the server, attempting to connect to a running
database...
07:26:00 [ 853] Connected to database successfully
07:26:00 [ 853] The number of prefetch rows has been reduced to 69 due to
the prefetch buffer
07:26:00 [ 853] limit. Consider using the PrefetchBuffer connection
parameter.
07:28:37 [ 853] Connection terminated abnormally; server socket shut down

07:30:00 [ 853] Communication function i_cs_HandleSQLPresError code 5
07:30:00 [ 853] Communication function StrmGetInd code 2
07:30:00 [ 853] Client disconnected



"Nick Elson [Sybase iAnywhere]" <@nick@dot@elson@at@sybase@dot@com@> wrote
in message news:4b0abc78$1 (AT) forums-1-dub (DOT) ..

Just a communication error ... nothing more specific than that.
Then entry stating "Connection terminated abnormally; server socket shut
down"
may be able to be matched with a related error on the server log for this
connection ... and if not, then it could be related to firewalls, routers or
stacks on the systems involved.

Maybe with server logging, you'll find out more the next time this
occures.

"Doug Stone" <doug.stone (AT) res-q (DOT) com> wrote