We have recently had 2 incidents where client variable
database storage appears to have failed in our clustered
environment. We have 2 servers that share a sybase 12.5.2 client
variable repository (CDATA/CGLOBAL). The problem seems to be
occuring when a table that the application uses gets blocked by an
unrelated application. When this happens, client variable storage
seems to fail - the 2 servers apparently use whatever client
variables they have in memory rather than getting the values from
There are no exceptions thrown, the application continues to
function normally except that each server has it's own copy of the
client variables. When we kill the process that has the table
locked up, the servers start using CDATA normally again.
The page that is getting blocked by the external process does
not update any client variables, but it does read them. The
inconsistent client variable problem occurs on other pages, not the
one being blocked.
I was able to sort of recreate the problem. I found that if I
renamed CDATA, no error is reported to the user. The database
exception (table not found) is logged, but not thrown on the page.
To the user the application appears to function normally. So this
demonstrates that updates to CDATA which result in database
exceptions fail silently and are not thrown to the page.
Has anyone else experienced silent exceptions in CDATA
updates? Are there any workarounds for this behavior? Our
application relies on client variables being consistent across
servers and really need for exceptions to be thrown to the page so
that the user is aware.
Windows Server 2003 SP1
database is sybase 12.5.2