ware-公羊
Master Note: Understanding the
944692.1]
修改时间
21-FEB-2011
类型
HOWTO
状态
PUBLISHED
In this
Document
Goal
Solution
1. Generic exception
2. JDBC code
3. Relationship to
4.
Causes
4.1.
Cause due to earlier problem that gave an error or
exception
4.1.1. Preceding exception:
interException, Cause: Unpublished JDBC Bug
4390875
4.1.2. Preceding exception: Bigger type
length than Maximum, Cause: JDBC Bug
3923624
4.1.3. Preceding exception:
emoryError
4.1.4. Preceding exception: No more
data to read from socket, Cause: Database Bug
5851267
4.1.5. Preceding exception: No more
data to read from socket, Cause: Database Bug
5364143
4.2.
Cause due to earlier problem that did not give an
error or exception
4.2.1. Sharing a connection between
threads
4.2.2. Insufficient memory
4.3. Cause not due to
earlier problem
4.3.1. JDBC syntax, Note
370271.1
5.
No cause found and no earlier problem
found
5.1.
Test with JDBC 11.2
5.2. Keep looking for an earlier
problem
5.3.
Provide a reproducible test case
6. Possible
workarounds
6.1. If the exception does not cause a
problem ignore it
6.2. Validate connection before
borrowing from pool
6.3. Catch exception, get new
connection, and redo whatever failed
References
Applies to:
JDBC - Version: 10.1.0.2 to 11.1.0.7 -
Release: 10.1 to 11.1
Information in
this document applies to any platform.
Goal
Over the past couple of
years you have occasionally seen the exception
inconsistent state
from a
large standalone Java application. The exceptions
were intermittent and could not be
reproduced at will. You were not able
to identify a cause for any of the occurrences of
the
exception. You ask if there is any
information that will help you to understand this
exception.
Solution
1. Generic exception
11.1. It indicates that an
internal inconsistency has been detected in the
JDBC connection but
it does not provide
information on what caused the inconsistency. The
exception no longer
occurs in JDBC
11.2.
2. JDBC code
At a particular point in the JDBC code
that handles a connection's communication between
client and server, the JDBC code
determines if an OALL8 object used by the
connection is in a
inconsistent state
by checking the value of the
of the
class
First the
code sets receiveState to zero. Then communication
occurs between client and
server. Then
the code checks to see if receiveState is still is
zero. It is expected to still be zero.
If receiveState is still zero then no
inconsistency has been detected in the connection
and
processing continues. If, however,
receiveState is no longer zero (which is
unexpected) the
OALL8 object is
considered to be in an inconsistent state and the
state
The
changed the value of
receiveState to a non-zero value. That
code that reports the
receiveState is not zero when it should
be zero.
The
following code snippets were obtained from the .
They show where the
code to
raise the exception no longer exists in JDBC
11.2.0.1.
JDBC 10.2.0.3:
if(receiveState != 0)
{
receiveState = 0;
qlException(447);
}
();
JDBC 11.1.0.7:
if(receiveState != 0)
{
receiveState = 0;
qlException(getConnectionDu
ringExceptionHand
ling(), 447);
}
();
JDBC 11.2.0.1:
if(receiveState != 0)
receiveState = 0;
();
The
line in ties
(in oracle/jdbc/driver).
ORA-17447=OALL8 is in an inconsistent state
3. Relationship to
In a number of service requests for an
The
JDBC Frequently Asked Questions (FAQ) at
/technetwork/database/enterprise-
edition/
provides the
following explanation.
What does
The Thin driver throws this exception
when it reads something from the RDBMS that it did
not
expect. This means that the
protocol engine in the Thin driver and the
protocol engine in the
RDBMS are out of
synch. There is no way to recover from this error.
The connection is dead.
You should try
to close it, but that will probably fail too.
If you get a
reproducible test case that generates this error,
please file a TAR with Oracle
Global
Support. Be sure to specify the exact version
numbers of the JDBC driver and the
RDBMS, including any patches.
4. Causes
In the
vast majority of cases where a cause has been
identified, that cause was not directly
responsible for the
responsible for another problem and the
consequence of the earlier problem.
Some examples of causes follow.
If an earlier problem is
found, whether or not it is a problem documented
below, resolve the
earlier problem and
determine if the
4.1. Cause
due to earlier problem that gave an error or
exception
4.1.1. Preceding exception:
interException, Cause: Unpublished
JDBC
Bug 4390875
This issue is described in
Note 549409.1
Driver.
Unpublished JDBC Bug 4390875 causes a
interException when executing a
certain
query. When the same Statement and Connection on
which the
interException occurred is
used to execute another query that query fails
with
Unpublished Bug 4390875 is described in
Note 4390875.8
NullPointerException from JDBC Thin
getString() with invalid AL32UTF8
characters
is fixed in JDBC 11.1.0.6.
4.1.2. Preceding exception:
Bigger type length than Maximum, Cause: JDBC Bug
3923624
This issue is
described in
Note 371815.1
'PROTOCOL EXCEPTION' FOLLOWED BY 'OALL8
IS IN AN INCONSISTENT STATE' WHEN USING
JDBC 10.1.0.3/10.1.0.4 and has been
reported in a number of service
requests.
Unpublished JDBC Bug 3923624 causes a
is followed by an
Unpublished Bug
3923624 is described in
Note
3923624.8
Bug 3923624 - SQLException
JDBC 10.1.0.4 and JDBC
10.2.0.1.
The
reference to unpublished Bug 4048311 GETTING
MAXIMUM
Unpublished Bug
4048311 in an internal bug and it reports the
issue occurring in JDBC
10.1.0.4. It is
a duplicate of unpublished Bug 3923624 which is
fixed in JDBC 10.1.0.4. So
unpublished
Bug 4048311 both occurs in and is fixed in JDBC
10.1.0.4. This is possible if the
issue
occurs in an early, internal JDBC 10.1.0.4 and is
fixed in a later, production JDBC
10.1.0.4.
4.1.3.
Preceding exception: emoryError