Obtaining an oracle.sql.STRUCT through a pooled JDBC connection

Question

Hello,
I am using WebLogic Server 10 and and Oracle 10 and I am trying to obtain a vendor-specific oracle.sql.STRUCT from a ResultSet using a pooled connection defined in Weblogic. I need the vendor-specific object, rather than simply the java.sql.Struct implementation, because a third party library requires it.
What gets returned in the ResultSet is a non-exposed WebLogic wrapper object which implements java.sql.Struct, but which cannot be cast to an oracle.sql.STRUCT. I can use reflection on this object to find and call the getVendorObj() method to obtain the oracle.sql.STRUCT, but this solution is not acceptable because this is not a published API and is not guaranteed not to change in future versions.
How can I reliably obtain a vendor-specific implementation of java.sql.Struct through a WebLogic connection pool in WebLogic Server 10?
Thanks for any advice,
-Dan Schwemlein

Answer 1

dan schwemlein wrote:
Joe,
Thanks again. With your guidance, I have arrived at the following approach, which I'll post for the benefit of others, and which I'd be thankful if you would validate:
1) Import the jar com.bea.core.datasource-1.0.0.0.jar from %BEA_HOME%\modules, which is the only location of the class WLConnection, which is the only class with the getVendorConnection() method you refer to.
2) Get the logical connection from the pooled data source, cast it to a WLConnection, call getVendorConnection() to obtain an OracleConnection (from the ojdbc jar), and use this connection to obtain the required oracle.sql.STRUCT from an OracleResultSet.
3) Be aware of the limitations and follow the guidelines in the document http://e-docs.bea.com/wls/docs81/jdbc/thirdparty.html#1043646 regarding security, error handling, releasing resources (close only the logical connection), etc.
Does this sound like the approach you had in mind?
Thanks again,
-Danyes.
Joe
>
Re: Obtaining an oracle.sql.STRUCT through a pooled JDBC connection
Posted: Jul 16, 2007 3:21 PM
dan schwemlein wrote:
Thanks for the quick response!I was working today...
Thank you for the information about the connection being closed.
I will look into using this configuration setting.
You say that you can describe a way to get a handle on an unwrapped
pool object using some documented WLS-specific code. Are you referring
here to the getVendorConnection() method?yes.
This method does not help me
get the oracle.sql.STRUCT object, because even the connection returned
by getVendorConnection() returns a wrapped WL java.sql.Struct object
from a call to getObject().I don't believe it. If you are running in WLS, with a local pool,
the getVendorConnection() will give you the Oracle connection,
which will give you an Oracle statement, etc, down to an oracle
STRUCT object. Once you have a direct reference to the oracle connection,
we're not in the picture when it returns something to you.
It would be great if getVendorObj() were
documented and could be counted on in future versions. To use this
method, one would still have to access it via Java reflection, because
the wrapper class and its getVendorObj() method would be exposed in an
API, correct? Could this method be exposed in the API, so that reflection
doesn't need to be used, or it is exposed somewhere that isn't documented?getVendorObj() is not yet exposed or therefore supported for the general
wrapped object, so you would have to start from the connection and
derive all subobjects from it.
Thanks again,
-Dan Schwemlein
Hello,
I am using WebLogic Server 10 and and Oracle 10 and I am trying to obtain a
vendor-specific oracle.sql.STRUCT from a ResultSet using a pooled connection
defined in Weblogic. I need the vendor-specific object, rather than simply
the java.sql.Struct implementation, because a third party library requires it.
What gets returned in the ResultSet is a non-exposed WebLogic wrapper object
which implements java.sql.Struct, but which cannot be cast to an oracle.sql.STRUCT.
I can use reflection on this object to find and call the getVendorObj() method to
obtain the oracle.sql.STRUCT, but this solution is not acceptable because this is
not a published API and is not guaranteed not to change in future versions.Understood. We all benefit from sticking to the J2EE standards,
but we could also wish Oracle had done so with it's driver objects.
I will assume your code is running in the WebLogic server, because
an external JVM can never access the real driver object, which will
always really be in the WLS JVM. No active JDBC object is serializable.
How can I reliably obtain a vendor-specific implementation of java.sql.Struct
through a WebLogic connection pool in WebLogic Server 10?There is no way to get a handle on an unwrapped pool object without using some
WLS-specific code, though I can describe a way with documented methods,
and/or I can get our documentation altered to say we'll support the
getVendorObj() method. We introspect every vendor object, and for those
implementations that have done the wise thing, projecting any non-standard
methods as an Interface, we are able to also project that Interface so
the vndor example code should work. However, in some poorly-done
cases, such as for some Oracle stuff, there is either no Interface,
or the Oracle code has extensions that take java.sql objects as input,
(at least that's the signature of the method) but two lines into the
method, the Oracle code assumes and casts the java.sql object to a concrete
Oracle object. In these use cases you need the direct unwrapped object.
We provide and document Connection.getVendorConnection(), and intend
getVendorObj() to serve the same for subobjects, but note the dangers
and responsibilities: We rely on our wrappers to implement the security
and thread-safety of our pooling system. Because user code can get
unrestricted access to the actual connection from most JDBC objects,
we can never trust that we have complete control once a vendor object
is exposed. Therefore, by default we will close and replace every JDBC
connection so exposed, as soon as the current thread is finished with
the pool connection. This hurts performance. We also document a pool
config setting that will tell us that you take responsibility for any such
problems, and not to close connections just because they've been exposed.
HTH,
Joe
Thanks for any advice,
-Dan Schwemlein