Using Orachk to Clean Up Concrete Classes for Application Continuity

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. In version 12.1.0.2.4 and later, 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 four 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.

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 -jdbcver 19.3 -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

import weblogic.jdbc.vendor.oracle.OracleThinBlob;

rs.next();
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

java.lang.ClassCastException:

weblogic.jdbc.wrapper.Blob_oracle_jdbc_proxy_oracle$1jdbc$1replay$1driver$1TxnReplayableBlob$2oracle$1jdbc$1internal$1OracleBlob$$$Proxy cannot be cast to weblogic.jdbc.vendor.oracle.OracleThinBlob

It must be changed to use the standard JDBC API

rs.next();
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 Oracle database.

The ORAchk download page is at https://support.oracle.com/epmos/faces/DocumentDisplay?id=1268927.2 .