yet another JZ0C0 problem

[Andre Noack]

I run into problems with jConnect when the Java process is very busy,
e.g. it takes more than 80% of CPU. When the java process reaches such a
high load level, I get a lot of JZ0C0 Exceptions.

In such a situation, all established connections to the database are
often closed all of a sudden. Creating a new connection by calling
"DriverManager.getConnection()" leads into a connection whose
"isClosed()" method returns "true" immediately after creation. It seems
to be that at this point it is not possible any longer to create healthy
connections.

Despite of that, the connections exist on the network level which leads
to a growing number of physical connections to the database. All
attempts to force a closing of these connections by calling
"Connection.close()" lead to a JZ0C0 Exception. The only way to get rid
of these corrupted connections is to call the garbage collector by
invoking "System.gc()".

I'm using JConnect5.2 (EBF11097) to connect to an ASE 11.9.2. There are
no limits (like maximum concurrent logins) reached on the database host.
The OS is either SunOS 5.8 or Linux 2.4.10. I tried multiple JDK
versions including 1.2.2, 1.3.1 and 1.4.1. The PreparedStatement objects
and connections are pooled in selfmade pools.

Any idea?

[odbcpse]

Hi Andre,

I am not sure what is happening here - sounds like connections increase
on the
Sybase database server, but somehow on your application (app server?
connection pooling?)
some threads (?) are not disconnecting.

Make sure the pooling code is closing up properly, seems that the
released connections may
not be reused. Make sure the pool code is handling this OK. Also, the
isClosed() method sends up "sp_mda"
to the ASE. Try setting a connection property in the connections, when
they physically connect
from the pool code - "IS_CLOSED_TEST"

props.put("IS_CLOSED_TEST", "INTERNAL");

INTERNAL means that the jdbc driver will check its internal properties
rather than make a roundtrip
to the database server to validate the connection.

Try those to see if it helps, or helps with the analysis. I think TDS
tracing might be too much at this point,

pv

[lance.a...@sun.com]

What if anything is in your ase log?

Do you have any tracing in your connection pool code?

lance