As I described in
the blog Part
2 - 12c Database and WLS - Application continuity, Application Continuity (AC) is a great feature
for avoiding errors to the user with minimal changes to the application and
configuration. Getting rid of any
references to Oracle concrete classes is the first step.
Oracle has a utility program that you can download
from MOS to validate various hardware, operating system, and software
attributes associated with the Oracle database and more (it’s growing). The program name is orachk. The latest version is 188.8.131.52.4 and starting
in this version, there are some checks available for applications running with AC.
There is enough documentation about getting started
with orachk so I’ll just say to download and unzip the file. The AC checking is part of a larger framework
that will have additional analysis in future versions. This article focuses on the analysis for
Oracle concrete classes in the application code.
AC is unable
to replay transactions that use oracle.sql deprecated concrete classes of
the form ARRAY, BFILE, BLOB, CLOB,
NCLOB, OPAQUE, REF, or STRUCT as a
variable type, a cast, the return type of a method, or calling a
constructor. See New
Jdbc Interfaces for Oracle types (Doc ID 1364193.1) for further information
about concrete classes. They must be modified for AC to work with the
application. See Using
API Extensions for Oracle JDBC Types for many examples of using the newer
Oracle JDBC types in place of the older Oracle concrete types.
There are three values that control the AC checking
(called acchk in orachk) for Oracle concrete classes. They can be set either on the command line or
via shell environment variable (or mixed). They are the following.
Command Line Argument
Shell Environment Variable
This must point to a version of asm-all-5.0.3.jar
This must point to the JAVA_HOME directory for a
To analyze the application code for references to
This test works with software classes compiled for
When you run the AC checking, the additional
checking about database server, etc. is turned off. It would be common to run the concrete class
checking on the mid-tier to analyze software that accesses the Oracle driver.
I chose some old QA test classes that I knew had
some bad usage of concrete classes and ran the test on a small subset for
illustration purposes. The command line
was the following.
$ ./orachk -asmhome /tmp/asm-all-5.0.3.jar -javahome
/tmp/jdk1.8.0_40 -appjar /tmp/appdir
This is a screen shot of the report details. There is additional information reported
about the machine, OS, database, timings, etc.
From this test run, I can see that my one test class
has five references to STRUCT that need to be changed to java.sql.Struct or oracle.jdbc.OracleStruct.
Note that WLS programmers have been using the
weblogic.jdbc.vendor.oracle.* interfaces for over a decade to allow for
wrapping Oracle concrete classes and this AC analysis doesn’t pick that up
(there are five weblogic.jdbc.vendor.oracle.* interfaces that correspond to
concrete classes). These should be
removed as well. For example, trying to
run with this ORACLE extension API and the WLS wrapper
OracleThinBlob blob = (OracleThinBlob)rs.getBlob(2);
java.io.OutputStream os = blob.getBinaryOutputStream();
on a Blob column using the normal driver works but
using the replay driver yields
$1OracleBlob$$$Proxy cannot be cast to
It must be changed to use the standard JDBC API
java.sql.Blob blob = rs.getBlob(2);
java.io.OutputStream os = blob.setBinaryStream(1);
So it’s time to remove references to the deprecated Oracle and
WebLogic classes and preferably migrate to the standard JDBC API’s or at least the new
Oracle interfaces. This will clean up
the code and get it ready to take advantage of Application Continuity in the
The ORAchk download page is at https://support.oracle.com/epmos/faces/DocumentDisplay?id=1268927.2 .