Problem:

CLASSCASTEXCEPTION when passing pooled connections to ARRAY.CREATEDESCRIPTOR

Resolution:

• Product Name: BES-AppServer
• Product Version: 5.x
• Product Component: Tomcat Webcontainer
• Platform/OS Version: Windows and Unix
• JDK/Compiler Version: 1.3.1 and 1.4.1

Description:

An Oracle JDBC Driver Bug using ArrayDescriptor.createDescriptor in BES generates the following exception

General Error: com.inprise.visitransact.jdbc2.ConnectionProxy

Answer/Solution:

An Oracle JDBC Driver Bug using ArrayDescriptor.createDescriptor in BES generates the following exception

General Error: com.inprise.visitransact.jdbc2.ConnectionProxy

This reproduces when using JDBC 2.0 pooled connections and is due to a bug in Oracle drivers in the OracleConnectionProxy class.

Workaround:

Use a vendor connection obtained from Borland ConnectionProxy

Connection physical = ((com.inprise.visitransact.jdbc2.ConnectionProxy connection_from_jndi).getVendorSQLConnection();
ArrayDescriptor desc = oracle.sql.ArrayDescriptor.createDescriptor("CHAR_ARRAY", physical);


************************************************************************
Oralce Bug Information
This item was obtained from metalink.oracle.com
************************************************************************


Bug No. 1628742
Filed 05-FEB-2001 Updated 11-FEB-2002
Product JDBC/OCI DRIVER Product Version 8.1.6
Platform IBM RS/6000 AIX Platform Version No Data
Database Version 8.1.6 Affects Platforms Generic
Priority Severe Loss of Service Status Not Feasible to fix, to Filer
Base Bug N/A Fixed in Product Version No Data

Problem statement:

CLASSCASTEXCEPTION WHEN PASSING POOLED CONNECTIONS TO ARRAY.CREATEDESCRIPTOR
------------------------------------------------------------------------



*** 02/05/01 01:04 pm *** .
=========================
PROBLEM: .
My ct is using a Pooled Connection class implementing the java.sql.Connection interface and tries to call a stored procedure with ARRAY parameters. . When ct passes the Pooled Connection class instance to ARRAY.createDescriptor, a ClassCastException is raised ... the Oracle JDBC driver is trying to cast the Pooled Connection instance to an OracleConnection, but this class does not extend OracleConnection, only implements the java.sql.Connection interface. . This is a violation of the contract advertised by createDescriptor, which says it requires a java.sql.Connection to be passed. .
=========================
DIAGNOSTIC ANALYSIS: .
I spoke at some length thru email with one of the JDBC developer"s about this and apparently this is not the only place this occurs. For assorted reasons, the JDBC drivers sometimes need access to methods only available from the underlying OracleConnection. . Although the developer admitted this was a problem and they were working to clean up some of these areas, I never got any formal read on whether they were treating this as a bug. At a minimum, the signature for the createDescriptor method needs to be changed, but this obviously won"t help ct much. . This scenario is likely to occur with increasing frequency because it is quite common to implement pooled connections (and possibly other features) wrapping the OracleConnection in some class and delegating calls to it ... i.e. not by extending OracleConnection. . Ct is currently using a workaround, but insisted I file a bug to ensure this problem was documented and did not get lost as future versions are released. . I leave it to BDE and/or development to determine whether this is to be dealt with as a bug or enhancement request. Personally, I think the signature of the createDescriptor method needs to be corrected at a minimum for this not to be considered
a bug.
=========================
WORKAROUND: . If the pooled
connection class has a method to return the OracleConnection, use this method to obtain the connection and pass it instead of the pooled connection. . Ct could not use this as the pooled connect class was provided by a 3rd party no such method ... and were not inclined to provide one since doing so breaks the encapsulation of the class. . Another workaround is to NOT USE ARRAYs ... this is the solution the ct ended up going with, but would rather not be limited in this manner forever so they would still like to see this problem cleaned up in a
future version. .
=========================
RELATED BUGS: . None. .
=========================
REPRODUCIBILITY: . I was unable to
reproduce since I did not have the WebSphere environment, but this should be verifiable by inspection of the code ... and at least one of the JDBC developers has already admitted to me that this sort of thing occurs. . Ct found this problem to exist in both the 8.1.6 and 8.1.7 drivers. Ct only tested the Thin driver, but I suspect this problem is
not unique to Thin. .
=========================
TESTCASE: . None.
See rationale in REPRODUCIBILITY section above. .
========================
STACK TRACE: . N/A . =========================
SUPPORTING INFORMATION: . N/A . ========================= 24 HOUR
CONTACT INFORMATION FOR P1 BUGS: . N/A . =========================
DIAL-IN INFORMATION: . N/A . ========================= IMPACT DATE:
. None specified. *** 02/05/01 05:58 pm *** (CHG: Asg->NEW OWNER) *** 03/06/01 10:19 pm *** (CHG: Sta->10) *** 03/06/01 10:19 pm *** *** 03/07/01 04:56 am *** (CHG: Sta->11) *** 03/07/01 04:56 am *** It shouldn"t be too difficult to provide a code snippet demonstrating the JDBC operation that is failing (i.e. the createDescriptor method call). The central problem is that it only occurs when using a Connection Pooling implementation that encapsulates the OracleConnection ... in WebSphere such an implementation already existed ... for me to provide a testcase outside that environment will require implementing an entire Connection Pooling class that mirrors the one provided by the other vendor ... this is nontrivial as it requires writing a substantial amount of code (i.e. implementing all of the Connection interface
methods) before I can even write the test case. I simply don"t have bandwidth to spend the amount of time it would require to do this ... and the ct didn"t have resources to do this either. . I will be more than happy to attempt a more detailed explanation that makes it clear what is happening if you think that will help, but a testcase just isn"t going to happen ... if that means the bug won"t get fixed, then I guess we"ll just have to live with that, but I still feel this is something that we could address without a test case (as I indicated, an inspection of the code should reveal whether we do, in fact, cast all Connection"s to OracleConnection"s in the createDescriptor method or some method it calls ... if we do, isn"t that incorrect?). Sorry I can"t provide more *** 03/07/01 04:56 am *** (CHG: Sta->16) *** 03/07/01 04:56 am *** Sorry ... should have set this to 16 status I think. *** 04/26/01 08:54 am *** (CHG: Asg->NEW OWNER) *** 07/31/01 05:19 pm *** *** 07/31/01 05:21 pm *** (CHG: Sta->11 Pri->2) *** 07/31/01 05:21 pm *** (CHG: Confirmed Flag->Y) *** 07/31/01 05:21 pm
*** *** 07/31/01 05:21 pm *** (CHG: Asg->NEW OWNER) *** 08/02/01 10:08 am *** (CHG: Asg->NEW OWNER) *** 08/06/01 11:11 am *** (CHG:
DevPri->2) *** 08/07/01 12:35 pm *** (CHG: Asg->NEW OWNER) *** 08/07/01 12:35 pm *** *** 08/13/01 09:45 am *** (CHG: FixBy->9.0.2
DevPri->1) *** 09/27/01 07:44 am *** (CHG: Asg->NEW OWNER) *** 09/27/01 07:44 am *** *** 10/10/01 06:25 pm *** (CHG: Sta->44) *** 10/10/01 06:25 pm *** *** 02/11/02 02:55 pm *** (CHG: Asg->NEW OWNER)
*** 02/11/02 02:55 pm *** Reasssigned to filer. This is functionality is in place in 9.2
.

------------------------------------------------------------------------

Author: Sean Chandler