XSU expecting oracle/jdbc/OracleConnection

We're developing a JSF+Spring application using NetBeans 5.5. as the IDE, running under Tomcat (5.5.17), which uses XSU to generate XML from a MySQL database.
On a linux workstation, the application runs sucessfully under NetBeans using the bundled tomcat server, but the same project built and run on a windows workstation returns java.lang.NoClassDefFoundError: oracle/jdbc/OracleConnection
at oracle.xml.sql.core.OracleXMLConvert.initObject(OracleXMLConvert.java:365)
at oracle.xml.sql.core.OracleXMLConvert.getXML(OracleXMLConvert.java:909)
at oracle.xml.sql.query.OracleXMLQuery.getXMLDOM(OracleXMLQuery.java:414)
at oracle.xml.sql.query.OracleXMLQuery.getXMLDOM(OracleXMLQuery.java:381)
at oracle.xml.sql.query.OracleXMLQuery.getXMLDOM(OracleXMLQuery.java:342)
from the following code
OracleXMLQuery query = new OracleXMLQuery(getConnection(), sql);
myClass.setDoc(query.getXMLDOM());
The getConnection() is from org.springframework.jdbc.core.support.JdbcDaoSupport
Am I missing some configuration information?
Thanks
Andrew

Re: Anyone able to help me out with this?

Similar Messages

Exception:org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper cannot be cast to oracle.jdbc.OracleConnection

Hi All,
i am using jdev version 11.1.1.5.0
and deployed my Adf application on Apache Tomcat 6.0.
in my use case i have created simple adf application using adf business component. create a vo based on eo and drag-drop on jspx page.
i have created JNDI data source in Apache server using edit context.xml file and add following line-
<Resource name="jdbc/TestDB" auth="Container"
 type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
 url="jdbc:oracle:thin:@localhost:1521:dst"
 username="jagrandb" password="jagrantest" maxActive="20" maxIdle="10"
 maxWait="-1" accessToUnderlyingConnectionAllowed="true" />
3.using same data source in my adf applicatioin as -
right click on AM --> Configuration-->edit-->select connection type jdbc datasource -->java:/comp/env/jdbc/TestDB
4. after that i have deployed my application on apace server but when i have running application i have got following error-
org.apache.tomcat.dbcp.dbcp.PoolingDataSource$PoolGuardConnectionWrapper cannot be cast to oracle.jdbc.OracleConnection
i have goggling and find following solution-
oracle.jdbc.driver.OracleConnection delConn = (oracle.jdbc.driver.OracleConnection) ((org.apache.tomcat.dbcp.dbcp.DelegatingConnection)c_stmt.getConnection()).getDelegate();
but my problem is that i'm using Adf Business Component so where i set following type casting.
Is there any method on ADF BC which handle JNDI Data source setting or any other way to do this.
thanks in Advance
Manish

Hi dvohra21,
thanks for reply.
i don't understand where i go to set accessToUnderlyingConnectionAllowed =true
i have already set this property on context.xml file
<Resource name="jdbc/TestDB" auth="Container"
 type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
 url="jdbc:oracle:thin:@localhost:1521:dst"
 username="jagrandb" password="jagrantest" maxActive="20" maxIdle="10"
 maxWait="-1" accessToUnderlyingConnectionAllowed="true" />
any other place where i set this propery
please elaborate this steps how to Configuree DBCP

How to import oracle.jdbc.OracleConnection

I'm sure this is something I'm supposed to know but it has been about a year since I have worked with JDeveloper and I have forgotten a few things.
I am looking at some code that includes import oracle.jdbc.OracleConnection with a wavy red line that gives the message "import oracle.jdbc.OracleConnection not found."
Where should I start to look for how to repair this?
Thanks,
Gregory

In your project properties, in the libraries and classpath section, add the library "Oracle JDBC".

How to avoid oracle.jdbc.driver.OracleConnection using

i'am new in Java but recently i've got a project on support.
Problem:
solution worked on jvm 1.4, now on 1.7.
Respectively, class oracle.jdbc.driver.OracleConnection has been used.
Now I need class oracle.jdbc.OracleConnection to use CLOB.createTemporary() but...I can't.
According to the docs, it's enough to replace in code and config files one class declaration on another. But NO. I replaced all of them in all config files and anyway, there was only oracle.jdbc.driver.OracleConnection has been created. (there is no explicit declaration of connection type in code, everything is configured in config files)
Project uses marven, mybatis-3.1.1. Database: oracle 9
Driver: ojdbc14-9.2.0.5.jar contains both classes: both oracle.jdbc.driver.OracleConnection (for backward compatibility) and oracle.jdbc.OracleConnection.
The matter is what should i do to use second one instead of first one.
May be there is some java cache? I do not know...
Anybody knows?

Now I need class oracle.jdbc.OracleConnection to use CLOB.createTemporary() but...I can't.
Why not? You have to explain, in detail, WHAT you are trying and WHY you say you "can't" do it.
According to the docs, it's enough to replace in code and config files one class declaration on another.
That is correct - this IS all that is required. Replace ALL references to 'oracle.jdbc.driver' in your code.
But NO. I replaced all of them in all config files and anyway, there was only oracle.jdbc.driver.OracleConnection has been created. (there is no explicit declaration of connection type in code, everything is configured in config files)
We can't SEE what 'config' information you say you changed. It is what is in the CODE that matters, not what is in a config file.
If the 'oracle.jdbc.driver' package is being imported by your code and a reference to 'Connection' is made Java will use it from the first package that it finds the class in.
You are using an ANCIENT jdbc jar file. That doc you linked to WARNS you that you should upgrade and that doc is over ten years old.
Remove that old jdbc jar file and use the current driver. Also remove references to the old package and replace them with references to the new package.
With code and jars that are that old you can expect to have problems trying to use additional features, especially extensions. I would be surprised if you didn't have other issues as well.
You need to perform code review to find all of the references that need to be corrected.

JGeometry / oracle.jdbc.OracleDriver ClassCastException

Hi-
I can't seem to store my JGeometry (from the SDO API) back to the database. The code that causes the problem is this:
===== Sample Code ========
import oracle.jdbc.OracleConnection;
OracleConnection oc = (OracleConnection) st.getConnection();
STRUCT struct = JGeometry.store((JGeometry)value,oc);
==========================
That last line of code throws this error:
===== Exception ============
05/01/04 16:50:26 [ERROR] ResultForm - Could not save the ResultBean <java.lang.ClassCastException>java.lang.ClassCastException
 at oracle.jdbc.driver.OracleConnection.unwrapCompletely(OracleConnection.java:5075)
 at oracle.jdbc.driver.OracleConnection.physicalConnectionWithin(OracleConnection.java:5126)
 at oracle.sql.TypeDescriptor.setPhysicalConnectionOf(TypeDescriptor.java:494)
 at oracle.sql.TypeDescriptor.<init>(TypeDescriptor.java:147)
 at oracle.sql.ArrayDescriptor.<init>(ArrayDescriptor.java:186)
 at oracle.sql.ArrayDescriptor.createDescriptor(ArrayDescriptor.java:118)
 at oracle.spatial.geometry.JGeometry.createDBDescriptors(JGeometry.java:1323)
 at oracle.spatial.geometry.JGeometry.store(JGeometry.java:1257)
 at gov.usgswim.wdnr.fishform.GeometryType.nullSafeSet(GeometryType.java:54)
=========================
It looks like the oracle.jdbc.driver.OracleConnection.unwrapCompletely method is assuming the connection to be something that it is not - but I'm stumped without the source code.
I've seen someone speculate that this is a classloader issue, but I'd have no idea how to resolve that within OC4J.
Here is my setup:
Running from JDev 9.0.5.2 using OC4J 9.0.5.
JDBC connections are provided via JNDI by specifying the datasource thru JDev. I've tried replacing the JDBC drivers that come with OC4J with the newer versions (that is, classes12.jar --> classes14.jar)
Database version is 10.1.0.3.0
I'm pretty much stuck until I can work this out, so any help would be appreciated.
Thanks in advance,
Eric Everman

Hi LJ - Thanks for the reply.
I'm leaving out detail about the framework I'm working within. For instance, the full method that saves the JGeometry back to the db is part of a Hibernate UserType for which I can't change the method signiture - thus the PreparedStatement.getConnection(). The full method looks like this:
=========== Java Method =================
public void nullSafeSet(PreparedStatement st, Object value, int index) throws HibernateException, SQLException {
STRUCT struct = null;
if (value != null) {
if (value instanceof JGeometry) {
JGeometry jg = (JGeometry)value;
System.out.println("Storing a Geom object to the db. Info:");
System.out.println(" Type: " + jg.getType());
System.out.println(" # of points: " + jg.getNumPoints());
System.out.println(" isPoint: " + jg.isPoint());
System.out.println(" X, Y: " + jg.getFirstPoint()[0] + ", " + jg.getFirstPoint()[1]);
//System.out.println(" elemInfo length: " + jg.getElemInfo().length); (throws error)
OracleConnection oc = (OracleConnection) st.getConnection();
struct = JGeometry.store(jg,oc);
} else {
throw new HibernateException("Cannot set GeometryType value to " + value.getClass().getName());
} //keep null value
st.setObject(index, struct);
==================================
==== Typical Output ==============
05/01/04 20:53:08 Storing a Geom object to the db. Info:
05/01/04 20:53:08 Type: 1
05/01/04 20:53:08 # of points: 1
05/01/04 20:53:08 isPoint: true
05/01/04 20:53:08 X, Y: 385343.3057, 562597.748
==================================
I've no reason to think that the connection I'd get from the prepared statement would be anything other then the connection returned from JNDI, but I'll try a simplified test to make sure.
My Geom is point data - would I expect JGeometry.getElemInfo() to return null in that case? Currently it does return null immediately after I load the JGeom from the database.

Workaround for using Oracle JDBC extension with WLS pooling

Reading the newsgroup I saw that many of us encountered the problems
with ClassCastException when tried to use Oracle JDBC extension
with WLS pooling. I also had.
In this case BEA recommends to use dangerous
method getVendorConnection() which exposes
the physical connection object to your code.
Yes it's really dangerous because of unsafe usage may breaks
WLS pooled connection(s).
Moreover, this practice will make your JDBC code
unportable (your JDBC code in addition to Oracle dependence
became Weblogic dependent):
void doSmth() {
Connection con = ...;
Connection vCon = ((WLConnection)con).getVendorConnection();
// + mess of usage con in one places and vCon in others
// (where Oracle extensions are needed)
// !Don't forget to don't close vCon!
Sux.
I found the workaround.
Introduction
============
Yes the real cause of ClassCastException is that
in depth of Oracle driver the casting
to class oracle.jdbc.driver.OracleConnection
(not to interface oracle.jdbc.OracleConnection)
is performed.
Someone can say that this is bug or pure desing.
Weblogic pooled connection provide dynamic
implementation for all public interfaces
which real physical (wrapped) connection object implements.
Great feature!
But I guess that all interface methods implemented
by simple call-delegation to physical (wrapped) connection object.
In case of oracle.jdbc.OracleConnection interface
this approach doesn't work for at least one its method:
public OracleConnection unwrap()
WLS pooled connection shoudn't implement this method by
delegation to physical connection object BUT should
return physical connection object itself!
// Wrong implementation of unwrap()
// delegation is used
public OracleConnection unwrap() {
return physicalConnection.unwrap();
// Right implementation of unwrap()
// physical connection returned
public OracleConnection unwrap() {
return physicalConnection;
Workaround
==========
1. Develop your own OracleConnection wrapper class:
import oracle.jdbc.OracleConnection;
import weblogic.jdbc.extensions.WLConnection;
public class MyOracleConnectionImpl implements OracleConnection {
private OracleConnection con;
public MyOracleConnectionImpl(OracleConnection connection)
throws SQLException
this.con = connection;
public OracleConnection unwrap() {
return (OracleConnection)
((WLConnection)con).getVendorConnection();
/* Implement all other methods by delegation to con object */
2. Don't get Connections directly from DataSource --
develop your own simple (may be static) utility
class which retrives Connections from dataSource
and returns them wrapped into your MyOracleConnectionImpl
to your code from some method:
puclic abstract class MyConnectionSource {
public static Connection getConnection() {
Connection con = // get it from DataSource
return new MyOracleConnectionImpl((OracleConnection)con);
3. Add attribute RemoveInfectedConnectionsEnabled="false"
to definition of your JDBCConnectionPool within config.xml
You may do it because of you `safely` use vendorConnection --
you don't expose it to application code.
4. Enjoy the Oracle JDBC extensions in your code!
Example:
Connection con = MyConnectionSource.getConnection;
ArrayDescriptor add =
ArrayDescriptor.createDescriptor("your_type", con);
Hope it helps to someone.
Best regards,
Eugene Voytitsky

Hello Eugene Voytitsky,
Thanks Eugene Voytitsky for your idea
I have tried the solution suggested by You, but it did not work.
It still throws ClassCastException.
I am sorry for posting the whole code of two classes below.
I did this to give you more clarity.
I am also indicating the place where the exception was thrown..
Please let me know if I am doing something wrong.
OracleConnection Wrapper class
package ejbTesting;
// sql imports
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DatabaseMetaData;
import java.sql.PreparedStatement;
import java.sql.SQLException;
import java.sql.SQLWarning;
import java.sql.Statement;
// util imports
import java.util.Map;
import java.util.Properties;
// imports from Oracle Driver Classes
import oracle.jdbc.OracleConnection;
import oracle.jdbc.OracleOCIFailover;
import oracle.jdbc.OracleSavepoint;
// import from Weblogic extensions
import weblogic.jdbc.extensions.WLConnection;
public class WeblogicConnectionWrapper implements OracleConnection
     // oracle connection object
     private OracleConnection connection;
     public WeblogicConnectionWrapper (OracleConnection orclConnection)
          try
               this.connection = orclConnection;
          catch(Exception unexpected )
               unexpected.printStackTrace();
     public OracleConnection unwrap()
          try
          // The datasource returns a weblogic.jdbc.pool.Connection
          // This needs to be type casted to weblogic.jdbc.extensions.WLConnection
          // Only this weblogic.jdbc.extensions.WLConnection CAN BE type casted
          // to OracleConnection
     return (OracleConnection) ((WLConnection) connection).getVendorConnection();
     catch(Exception sqlException )
          sqlException.printStackTrace ();
          return null;
     /* Implement all other methods by delegation to connection object */
public Connection _getPC()
return connection._getPC();
public void archive(int i, int j, String s)
throws SQLException
connection.archive(i, j, s);
public void assertComplete()
throws SQLException
connection.assertComplete();
public void clearWarnings()
throws SQLException
connection.clearWarnings();
public void close()
throws SQLException
connection.close();
public void commit()
throws SQLException
connection.commit();
public Statement createStatement()
throws SQLException
return connection.createStatement();
public Statement createStatement(int i, int j)
throws SQLException
return connection.createStatement(i, j);
public boolean getAutoClose()
throws SQLException
return connection.getAutoClose();
public boolean getAutoCommit()
throws SQLException
return connection.getAutoCommit();
public CallableStatement getCallWithKey(String s)
throws SQLException
return connection.getCallWithKey(s);
public String getCatalog()
throws SQLException
return connection.getCatalog();
public boolean getCreateStatementAsRefCursor()
return connection.getCreateStatementAsRefCursor();
public int getDefaultExecuteBatch()
return connection.getDefaultExecuteBatch();
public int getDefaultRowPrefetch()
return connection.getDefaultRowPrefetch();
public Object getDescriptor(String s)
return connection.getDescriptor(s);
public boolean getExplicitCachingEnabled()
throws SQLException
return connection.getExplicitCachingEnabled();
public boolean getImplicitCachingEnabled()
throws SQLException
return connection.getImplicitCachingEnabled();
public boolean getIncludeSynonyms()
return connection.getIncludeSynonyms();
public Object getJavaObject(String s)
throws SQLException
return connection.getJavaObject(s);
public DatabaseMetaData getMetaData()
throws SQLException
return connection.getMetaData();
public Properties getProperties()
return connection.getProperties();
public boolean getRemarksReporting()
return connection.getRemarksReporting();
public boolean getRestrictGetTables()
return connection.getRestrictGetTables();
public String getSQLType(Object obj)
throws SQLException
return connection.getSQLType(obj);
public String getSessionTimeZone()
return connection.getSessionTimeZone();
public int getStatementCacheSize()
throws SQLException
return connection.getStatementCacheSize();
public PreparedStatement getStatementWithKey(String s)
throws SQLException
return connection.getStatementWithKey(s);
public int getStmtCacheSize()
return connection.getStmtCacheSize();
public short getStructAttrCsId()
throws SQLException
return connection.getStructAttrCsId();
public boolean getSynchronousMode()
return connection.getSynchronousMode();
public int getTransactionIsolation()
throws SQLException
return connection.getTransactionIsolation();
public Map getTypeMap()
throws SQLException
return connection.getTypeMap();
public String getUserName()
throws SQLException
return connection.getUserName();
public boolean getUsingXAFlag()
return connection.getUsingXAFlag();
public SQLWarning getWarnings()
throws SQLException
return connection.getWarnings();
public boolean getXAErrorFlag()
return connection.getXAErrorFlag();
public boolean isClosed()
throws SQLException
return connection.isClosed();
public boolean isLogicalConnection()
return connection.isLogicalConnection();
public boolean isReadOnly()
throws SQLException
return connection.isReadOnly();
public String nativeSQL(String s)
throws SQLException
return connection.nativeSQL(s);
public Object openJoltConnection(String s, short word0, short word1)
return connection.openJoltConnection(s, word0, word1);
public void oracleReleaseSavepoint(OracleSavepoint oraclesavepoint)
throws SQLException
connection.oracleReleaseSavepoint(oraclesavepoint);
public void oracleRollback(OracleSavepoint oraclesavepoint)
throws SQLException
connection.oracleRollback(oraclesavepoint);
public OracleSavepoint oracleSetSavepoint()
throws SQLException
return connection.oracleSetSavepoint();
public OracleSavepoint oracleSetSavepoint(String s)
throws SQLException
return connection.oracleSetSavepoint(s);
public int pingDatabase(int i)
throws SQLException
return connection.pingDatabase(i);
public CallableStatement prepareCall(String s)
throws SQLException
return connection.prepareCall(s);
public CallableStatement prepareCall(String s, int i, int j)
throws SQLException
return connection.prepareCall(s, i, j);
public CallableStatement prepareCallWithKey(String s)
throws SQLException
return connection.prepareCallWithKey(s);
public PreparedStatement prepareStatement(String s)
throws SQLException
return connection.prepareStatement(s);
public PreparedStatement prepareStatement(String s, int i, int j)
throws SQLException
return connection.prepareStatement(s, i, j);
public PreparedStatement prepareStatementWithKey(String s)
throws SQLException
return connection.prepareStatementWithKey(s);
public void purgeExplicitCache()
throws SQLException
connection.purgeExplicitCache();
public void purgeImplicitCache()
throws SQLException
connection.purgeImplicitCache();
public void putDescriptor(String s, Object obj)
throws SQLException
connection.putDescriptor(s, obj);
public void registerApiDescription(String s, short word0, short word1, String
s1)
connection.registerApiDescription(s, word0, word1, s1);
public void registerSQLType(String s, Class class1)
throws SQLException
connection.registerSQLType(s, class1);
public void registerSQLType(String s, String s1)
throws SQLException
connection.registerSQLType(s, s1);
public void registerTAFCallback(OracleOCIFailover oracleocifailover, Object
obj)
throws SQLException
connection.registerTAFCallback(oracleocifailover, obj);
public void rollback()
throws SQLException
connection.rollback();
public void setAutoClose(boolean flag)
throws SQLException
connection.setAutoClose(flag);
public void setAutoCommit(boolean flag)
throws SQLException
connection.setAutoCommit(flag);
public void setCatalog(String s)
throws SQLException
connection.setCatalog(s);
public void setCreateStatementAsRefCursor(boolean flag)
connection.setCreateStatementAsRefCursor(flag);
public void setDefaultExecuteBatch(int i)
throws SQLException
connection.setDefaultExecuteBatch(i);
public void setDefaultRowPrefetch(int i)
throws SQLException
connection.setDefaultRowPrefetch(i);
public void setExplicitCachingEnabled(boolean flag)
throws SQLException
connection.setExplicitCachingEnabled(flag);
public void setImplicitCachingEnabled(boolean flag)
throws SQLException
connection.setImplicitCachingEnabled(flag);
public void setIncludeSynonyms(boolean flag)
connection.setIncludeSynonyms(flag);
public void setReadOnly(boolean flag)
throws SQLException
connection.setReadOnly(flag);
public void setRemarksReporting(boolean flag)
connection.setRemarksReporting(flag);
public void setRestrictGetTables(boolean flag)
connection.setRestrictGetTables(flag);
public void setSessionTimeZone(String s)
throws SQLException
connection.setSessionTimeZone(s);
public void setStatementCacheSize(int i)
throws SQLException
connection.setStatementCacheSize(i);
public void setStmtCacheSize(int i)
throws SQLException
connection.setStmtCacheSize(i);
public void setStmtCacheSize(int i, boolean flag)
throws SQLException
connection.setStmtCacheSize(i, flag);
public void setSynchronousMode(boolean flag)
connection.setSynchronousMode(flag);
public void setTransactionIsolation(int i)
throws SQLException
connection.setTransactionIsolation(i);
public void setTypeMap(Map map)
throws SQLException
connection.setTypeMap(map);
public void setUsingXAFlag(boolean flag)
connection.setUsingXAFlag(flag);
public void setWrapper(OracleConnection oracleconnection)
connection.setWrapper(oracleconnection);
public void setXAErrorFlag(boolean flag)
connection.setXAErrorFlag(flag);
public void shutdown(int i)
throws SQLException
connection.shutdown(i);
public void startup(String s, int i)
throws SQLException
connection.startup(s, i);
Util class to get Wrapped Connections from
datasource
package ejbTesting;
// j2ee imports
import javax.naming.InitialContext;
import javax.sql.DataSource;
// sql imports
import java.sql.Connection;
// imports from Oracle Driver Classes
import oracle.jdbc.OracleConnection;
* Wrapper class for the DataSource Connection from Weblogic pool
public class DataSourceConnectionWrapper
     // datasource variable
     private static transient DataSource datasource = null;
     private static String dbName = "jdbc/workbench";
* Method that returns the database connection
     public static Connection getConnection()
          try
               // initialsing the datasource object
               initialiseDataSource ();
               // Getting a connection from the datasource
               Connection con = datasource.getConnection( );
               // wrapping it custom wrapper class and
               // returning the connection object
               return new WeblogicConnectionWrapper((OracleConnection)con);
          catch(Exception exception )
               exception.printStackTrace();
               return null;
     private static void initialiseDataSource( ) throws Exception
if ( datasource == null )
try
InitialContext ic = new InitialContext( );
datasource = (DataSource) ic.lookup( dbName );
catch (Exception ne )
throw new Exception( "NamingException while looking up DataSource with
JNDI name" +
dbName + ": \n" + ne.getMessage( ) );
Exception Stack Trace
The line 46 in DataSourceConnectionWrapper
corresponds to
return new WeblogicConnectionWrapper((OracleConnection)con);
Which I feel is logical as the connection which we get from Weblogic
datasource cannot be type casted to OracleConnection
java.lang.ClassCastException: weblogic.jdbc.pool.Connection
at ejbTesting.DataSourceConnectionWrapper.getConnection(DataSourceConnectionWrapper.java:46)

Oracle XSU class oracle.xml.sql.dataset.OracleXMLDataSetExtJdbc bug

Hi,
The oracle class oracle.xml.sql.dataset.OracleXMLDataSetExtJdbc needlessly casts the java.sql.Connection it receives in its constructor to oracle.jdbc.driver.OracleConnection.
This will work fine in most circumstances, but throws a class cast exception when a proxified connection is used such that the connection is a wrapper rather than an instance of OracleConnection.
I believe there would be absolutely no need for the oracle class to cast the connection to its derived form.
Please correct this problem in the XSU as soon as possible.
Thanks in advance,
-- Dave Campbell

Yes, of course I have. If you carefully see my first post, you will notice that I get an
'ORA-00904: invalid column name' error when I - in purpose - use an invalid Query, which means that communication with Oracle DB is fine. The problem appears when my Query does return some results. It's really confusing me...
Any other ideas?
thanks!
-n-
<BLOCKQUOTE>quote:<HR>Originally posted by Jinyu Wang ([email protected]):
Have you include JDBC lib in your classpath?<HR></BLOCKQUOTE>
null

How to get comparable Oracle JDBC performance using Java 1.4 vs 1.1.7?

Our application makes extensive use of JDBC to access an Oracle database. We wrote it a number of years ago using java 1.1.7 and we have been unable to move to new versions of java because of the performance degradation.
I traced the problem to JDBC calls. I can reproduce the problem using a simple program that simply connects to the database, executes a simple query and then reads the data. The same program running under java 1.4 is about 60% slower than under java 1.1.7. The query is about 80% slower and getting the data is about 150% slower!
The program is attached below. Note, I run the steps twice as the first time the times are much larger which I attribute to java doing some initializations. So the second set of values I think are more representative of the actual performance in our application where there are numerous accesses to the database. Specifically, I focus on step 4 which is the execute query command and step 5 which is the data retrieval step. The table being read has 4 columns with 170 tuples in it.
Here are the timings I get when I run this on a Sparc Ultra 5 running
SunOs 5.8 using an Oracle database running 8.1.7:
 java 1.1.7 java 1.4
 overall: 2.1s 3.5s
 step 1: 30 200
 step 2: 886 2009
 step 3: 2 2
 step 4: 9 17
 step 5: 122 187
 step 6: 1 1
 step 1: 0 0
 step 2: 203 161
 step 3: 0 1
 step 4: 8 15 <- 87% slower
 step 5: 48 117 <- 143% slower
 step 6: 1 2I find the same poor performance from java versions 1.2 and 1.3.
I tried using DataDirect's type 4 JDBC driver which gives a little better performance but overall it is still much slower than using java 1.1.7.
Why do the newer versions of java have such poor performance when using JDBC?
What can be done so that we can have performance similar to java 1.1.7
using java 1.4?
========================================================================
import java.util.*;
import java.io.*;
import java.sql.*;
public class test12 {
 public static void main(String args[]) {
 try {
 long time1 = System.currentTimeMillis();
/* step 1 */ DriverManager.registerDriver(
 new oracle.jdbc.driver.OracleDriver());
 long time2 = System.currentTimeMillis();
/* step 2 */ Connection conn = DriverManager.getConnection (
 "jdbc:oracle:thin:@dbserver1:1521:db1","user1","passwd1");
 long time3 = System.currentTimeMillis();
/* step 3 */ Statement stmt = conn.createStatement();
 long time4 = System.currentTimeMillis();
/* step 4 */ ResultSet rs = stmt.executeQuery("select * from table1");
 long time5 = System.currentTimeMillis();
/* step 5 */ while( rs.next() ) {
 int message_num = rs.getInt(1);
 String message = rs.getString(2);
 long time6 = System.currentTimeMillis();
/* step 6 */ rs.close(); stmt.close();
 long time7 = System.currentTimeMillis();
 System.out.println("step 1: " + (time2 - time1) );
 System.out.println("step 2: " + (time3 - time2) );
 System.out.println("step 3: " + (time4 - time3) );
 System.out.println("step 4: " + (time5 - time4) );
 System.out.println("step 5: " + (time6 - time5) );
 System.out.println("step 6: " + (time7 - time6) );
 System.out.flush();
 } catch ( Exception e ) {
 System.out.println( "got exception: " + e.getMessage() );
 ... repeat the same 6 steps again...
}

If I run my sample program with the -server option, it
takes a lot longer (6.8s vs 3.5s).Which has to be expected, as the -server option optimizes for long running programs - so it shoudl go with my second suggestion, more below...
I am not certain what you mean by "just let the jvm
running". Our users issue a command (in Unix) which
invokes one of our java programs to access or update
data in a database. I think what you are suggesting
would require that I rewrite our application to have a
java program always running on the users workstation
and to also rewrite our
commands (over a hundred) to some how pass data and
receive data with this new server java program. That
does not seem a very reasonable just to move to a new
version of java. Or are you suggesting something
else?No I was just suggestion what you descript. But if this is not an option, then maybe you should merge your java-programs to C or another native language. Or you could try the IBM-JDK with the -faststart (or similar) option. If thew Unix you mention is AIX, then there would be the option of a resetable-vm. But I cannot say if this VM would solve your problem. Java is definitly not good for applications which only issue some unqiue commands because the hotspot-compiler can not be efficiently used there. You can only try to get 1.1.7 performance by experimenting with vm-parameters (execute java -X).

Oracle JDBC driver 11.2.0.3 is reported as client version 11.2.0.2

Greetings everyone,
I wonder if other folks are experiencing the same:
We have upgraded our JDBC driver to latest ojdbc6.jar (2,714,189 bytes) - 11.2.0.3
Everything looks great, except that on the server side it is reported as client version 11.2.0.2
JVM side:
===== Database info =====
DatabaseProductName: Oracle
DatabaseProductVersion: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
DatabaseMajorVersion: 11
DatabaseMinorVersion: 2
===== Driver info =====
DriverName: Oracle JDBC driver
DriverVersion: 11.2.0.3.0
DriverMajorVersion: 11
DriverMinorVersion: 2
Database side:
select client_driver, client_version from v$session_connect_info
(null), 11.2.0.2.0
Is that expected behavior or the property is not updated between releases?
Andrey
Edited by: 907164 on Jan 10, 2012 12:09 PM

Hi ,
Thank you so much for your reply.
That was the exact information that I needed.
Could you also tell me from where can I get the information of future releases.
Regards,
Stacey.

Differences between Oracle JDBC Thin and Thick Drivers

If any body is looking for this information...
============================================================
I have a question concerning the Oracle JDBC thin vs. thick drivers
and how they might affect operations from an application perspective.
We're in a Solais 8/Oracle 8.1.7.2 environment. We have several
applications on several servers connecting to the Oracle database.
For redundancy, we're looking into setting up TAF (transparent
application failover). Currently, some of our apps use the Oracle
JDBC thin drivers to talk to the database, with a connection
string that like this:
 jdbc:oracle:thin:@host:port:ORACLE_SID 
In a disaster recovery mode, where we would switch the database
from one server to another, the host name in the above string
would become invalid. That means we have to shut down our application
servers and restart them with an updated string.
Using the Oracle OCI (thick) driver though, allows us to connect
to a Net8 service instead of a specific server:
 jdbc:oracle:oci8:@NET8_SERVICE_NAME 
Coupled with the FAILOVER=ON option configured in Net8, it is
then possible to direct a connection from the first server to
the failover database on another server. This is exactly what
we would like to do.
My question is, from an application perspective, how is the Oracle
thick driver different from the thin driver? If everything
else is "equal" (i.e. the thick driver is compatible with the
app servers) would there be something within the the thick/OCI
driver that could limit functionality vs. the thin driver?
My understand, which obviously is sketchy, is that the thick
driver is a superset of the thin driver. If this is the case,
and for example if all database connections were handled through
a configuration file with the above OCI connection string, then
theoretically the thick driver should work.
============================================================

In the case with the Oracle, they provide a thin driver that is a 100% Java driver for client-side use without the need of an Oracle installation (maybe that's why we need to input server name and port number of the database server). This is platform indipendent, and has good performance and some features.
The OCI driver on the other hand is not java, require Oracle installation, platform dependent, performance is faster, and has a complete list of all the features.

========================================================
I hope this is what you expect.
JDBC OCI client-side driver: This is a JDBC Type 2 driver that uses Java native methods to call entrypoints in an underlying C library. That C library, called OCI (Oracle Call Interface), interacts with an Oracle database. The JDBC OCI driver requires an Oracle (7.3.4 or above) client installation (including SQL*Net v2.3 or above) and all other dependent files. The use of native methods makes the JDBC OCI driver platform specific. Oracle supports Solaris, Windows, and many other platforms. This means that the Oracle JDBC OCI driver is not appropriate for Java applets, because it depends on a C library to be preinstalled.
JDBC Thin client-side driver: This is a JDBC Type 4 driver that uses Java to connect directly to Oracle. It emulates Oracle's SQL*Net Net8 and TTC adapters using its own TCP/IP based Java socket implementation. The JDBC Thin driver does not require Oracle client software to be installed, but does require the server to be configured with a TCP/IP listener. Because it is written entirely in Java, this driver is platform-independent. The JDBC Thin driver can be downloaded into any browser as part of a Java application. (Note that if running in a client browser, that browser must allow the applet to open a Java socket connection back to the server.
JDBC Thin server-side driver: This is another JDBC Type 4 driver that uses Java to connect directly to Oracle. This driver is used internally by the JServer within the Oracle server. This driver offers the same functionality as the client-side JDBC Thin driver (above), but runs inside an Oracle database and is used to access remote databases. Because it is written entirely in Java, this driver is platform-independent. There is no difference in your code between using the Thin driver from a client application or from inside a server.
======================================================
How does one connect with the JDBC Thin Driver?
The the JDBC thin driver provides the only way to access Oracle from the Web (applets). It is smaller and faster than the OCI drivers, and doesn't require a pre-installed version of the JDBC drivers.
import java.sql.*;
class dbAccess {
public static void main (String args []) throws SQLException
DriverManager.registerDriver (new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection
("jdbc:oracle:thin:@qit-uq-cbiw:1526:orcl", "scott", "tiger");
// @machineName:port:SID, userid, password
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select BANNER from SYS.V_$VERSION");
while (rset.next())
System.out.println (rset.getString(1)); // Print col 1
stmt.close();
How does one connect with the JDBC OCI Driver?
One must have Net8 (SQL*Net) installed and working before attempting to use one of the OCI drivers.
import java.sql.*;
class dbAccess {
public static void main (String args []) throws SQLException
try {
Class.forName ("oracle.jdbc.driver.OracleDriver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
Connection conn = DriverManager.getConnection
("jdbc:oracle:oci8:@qit-uq-cbiw_orcl", "scott", "tiger");
// or oci7 @TNSNames_Entry, userid, password
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select BANNER from SYS.V_$VERSION");
while (rset.next())
System.out.println (rset.getString(1)); // Print col 1
stmt.close();
=================================================================

Wow, not sure what your question was, but there sure was a lot of information there...
There really is only one case where failover occurs, and it would not normally be in a disaster recovery situation, where you define disaster recovery as the obliteration of your current server farm, network and concievably the operational support staff. This would require a rebuild of your server, network etc and isn't something done with software.
Fail over is normally used for high availablity that would take over in case of hardware server failure, or when your support staff wants to do maintenance on the primary server.
Using the thin and thick driver should have ZERO affect on a failover. Transparent failover will make the secondary server the same IP as the primary, therefore the hostname will still point to the appropriate server. If you are doing this wrong, then you will have to point all your applications to a new IP address. This should be something that you tell your management is UNACCEPTABLE in a fail-over situation, since it is almost sure to fail to fail-over.
You point out that you are providing the TNSNAME, rather than the HOSTNAME when using the thick driver. That's true within your application, but that name is resolved to either a HOSTNAME, or IP ADDRESS before it is sent to the appropriate Oracle server/instance. It is resolved using either a NAME server (same as DNS server but for Oracle), or by looking at a TNSNAMES file. Since the TNSNAMES files profilerate like rabbits within an organization you don't want a fail over that will make you find and switch all the entries, so you must come up with a fail over that does not require it.
So, the application should not be concerned with either the hostname, or the IP address changing during fail over. That makes use of the thin or thick client acceptable for fail over.
Don't know if this will help, but this shows the communication points.
THIN DRIVER
client --> dns --> server/port --> SID
THICK DRIVER
client --> names server --> dns --> server/port --> SID
client --> tnsnames --> dns --> server/port --> SID

Oracle JDBC Connectivity

I am trying to connect to oracle8.0.5 database from JDK1.3 on
windows 2000 os
my program code is as follows
import java.sql.*;
class JEmpt{
public static void main (String args [])
 throws SQLException {
 try
 Class.forName("oracle.jdbc.driver.OracleDriver");
 Connection conn =
 DriverManager.getConnection
("jdbc:oracle:thin:@127.0.0.1:1521:ORCL","SYSTEM","MANAGER");
 Statement stmt = conn.createStatement ();
 ResultSet rset = stmt.executeQuery ("select
ENAME from EMP");
 while (rset.next ()) {
 System.out.println (rset.getString (1));
 catch(Exception e)
 System.out.println("Exception : "+e.getMessage
but i get the following error
Exception in thread "main" java.sql.SQLException: Connection
refused: no further information
at oracle.jdbc.dbaccess.DBError.check_error<DBError.java:228>
at
oracle.jdbc.driver.OracleConnection.<init><OracleConnection.java:
110>
at oracle.jdbc.driver.OracleDriver.connect<OracleDriver.java:148>
at java.sql.DriverManager.getConnection<Unknown Source>
at java.sql.DriverManager.getConnection<Unknown Source>
at Employee.main<Employee.java:23>
your help wii be highly appreciated
looking forward for yr reply
lekha

Hi lekha
try this:
import oracle.jdbc.driver.*;
DriverManager.registerDriver(new OracleDriver());
conn = DriverManager.getConnection(...)
and ensure that your CLASSPATH can see
classes111.zip/classes12.zip.
Tarik

Bad support for ts hint in Oracle jdbc driver (for preparedStatement)

hi
I have the following SQL
SELECT TRUNC({ ts '2004-01-01 00:00:00.0' }) FROM ET1_ELEMENT
With the jdbc.odbc driver the following meta data is returned:
ResultSet meta data are...
Column [1]
name [TRUNC(TO_DATE('2004-01-0100:00]
type [93]
class name [java.sql.Timestamp]
which is fine.
Nevertheless with Oracle thin driver I got an SQL exception:
The SQL Error is:
ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTAMP
internal exception:
(class java.sql.SQLException):
java.sql.SQLException: ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTAMP
If I use the TO_DATE in the sentence (e.g. t_date('2004-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS')) everything is fine on both driver.
Any idea on the problem? Is it a bug?
Thanks

Mikael,
I couldn't ascertain your environment from your post, so the below may be irrelevant for you. But in the hope that is isn't...
I tried your example on an Oracle 9i (9.2.0.4) database on SUN [sparc] Solaris 9, with J2SE 1.4.2_04 and the "ojdbc14.jar" [JDBC] driver. If I remove the "trunc" function, then I do not get an Oracle error. I must admit, though, that I don't understand why you need to trunc(ate) a literal value. All that the "trunc" function does is set the time part -- the hours, minutes, seconds, etc. -- of your timestamp to (all) zeroes -- which is what you have in your literal, anyway, so why the need for "trunc"?
I believe the Oracle JDBC driver converts the java sql-escape syntax -- "{ts '2004-01-01 00:00:00.0'}" -- to a call to the "to_date" function, anyway. Possibly one way to verify this would be to use P6 Spy. If I am correct, then it would only be logical that Oracle allows you to use the sql-escape syntax wherever it is all right to use the "to_date" function. But then again, I guess that
select trunc(to_date('2004-01-01 00:00','YYYY-MM-DD HH24:MI')
from ET1_ELEMENTis allowable syntax anyway. So I guess maybe that this may be a bug in the JDBC driver. Have you checked the MetaLink Web site?
Good Luck,
Avi.

Deadlock in oracle JDBC driver

I've been doing testing on a 12 CPU SunFire 6800 and am seeing the
Oracle JDBC driver that ships with weblogic deadlock in Java. Has
anyone else come across this?
Also, does anyone know how to find the version of the oracle driver or simply know which version WebLogic 6.1 ships with?
thank you
FOUND A JAVA LEVEL DEADLOCK:
"ExecuteThread: '180' for queue: 'default'":
waiting to lock monitor 0xcbb28 (object 0xdee1d070, a oracle.jdbc.driver.OraclePreparedStatement),
which is locked by "ExecuteThread: '73' for queue: 'default'"
"ExecuteThread: '73' for queue: 'default'":
waiting to lock monitor 0xcbc78 (object 0xdec416b8, a oracle.jdbc.driver.OracleConnection),
which is locked by "ExecuteThread: '180' for queue: 'default'"
JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
Java Stack for "ExecuteThread: '180' for queue: 'default'":
==========
     at oracle.jdbc.driver.OraclePreparedStatement.sendBatch(OraclePreparedStatement.java:431)
     at oracle.jdbc.driver.OracleConnection.commit(OracleConnection.java:838)
     at weblogic.jdbc.jts.Connection.internalCommit(Connection.java:697)
     at weblogic.jdbc.jts.Connection.commit(Connection.java:415)
     at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:1180)
     at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:419)
     at weblogic.transaction.internal.ServerSCInfo.startCommit(ServerSCInfo.java:233)
     at weblogic.transaction.internal.ServerTransactionImpl.localCommit(ServerTransactionImpl.java:1397)
     at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:1940)
     at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:1886)
     at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:221)
     at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
     at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:231)
     at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:46)
     at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
     at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doGet(HttpRequestHandlerServlet.java:78)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Java Stack for "ExecuteThread: '73' for queue: 'default'":
==========
     at oracle.jdbc.driver.OracleConnection.getDefaultRowPrefetch(OracleConnection.java:1263)
     at oracle.jdbc.driver.OracleStatement.setFetchSize(OracleStatement.java:4878)
     at weblogic.jdbc.common.internal.ConnectionEnv.cleanUpStatementForReUse(ConnectionEnv.java:747)
     at weblogic.jdbc.common.internal.ConnectionEnv.dropStatement(ConnectionEnv.java:719)
     at weblogic.jdbc.jts.Statement.close(Statement.java:231)
     at weblogic.jdbc.rmi.internal.StatementImpl.close(StatementImpl.java:97)
     at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:123)
     at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:113)
     at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseStatement(PersistenceManagerImpl.java:596)
     at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:562)
     at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:531)
     at com.fourthpass.wpserver.billingentities.PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.ejbRemove(PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.java:1135)
     at weblogic.ejb20.manager.DBManager.remove(DBManager.java:627)
     at weblogic.ejb20.internal.EntityEJBObject.remove(EntityEJBObject.java:117)
     at com.fourthpass.wpserver.billingentities.PendingBillingInfoBeanCMP_6hg1f2_EOImpl.remove(PendingBillingInfoBeanCMP_6hg1f2_EOImpl.java:559)
     at com.fourthpass.wpserver.billing.BillingBean.movePendingToActiveBilling(BillingBean.java:1442)
     at com.fourthpass.wpserver.billing.BillingBean.reportSuccessfulInstallation(BillingBean.java:1349)
     at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:968)
     at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:937)
     at com.fourthpass.wpserver.billing.BillingBean_t3moiz_EOImpl.reportApplicationInstallStatusCode(BillingBean_t3moiz_EOImpl.java:1265)
     at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.handleOtaEvent(InstallNotifyCommand.java:187)
     at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.process(InstallNotifyCommand.java:94)
     at com.fourthpass.wpserver.request.handlers.MASRequestHandler.process(MASRequestHandler.java:90)
     at com.fourthpass.wpserver.request.RequestProcessorBean.processRequest(RequestProcessorBean.java:113)
     at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:37)
     at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
     at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
     at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doPost(HttpRequestHandlerServlet.java:89)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
     at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
     at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
     at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
     at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
     at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Found 1 deadlock.

Chad Urso McDaniel wrote:
I've been doing testing on a 12 CPU SunFire 6800 and am seeing the
Oracle JDBC driver that ships with weblogic deadlock in Java. Has
anyone else come across this?
Also, does anyone know how to find the version of the oracle driver or simply know which version WebLogic 6.1 ships with?Oracle does have later driver versions, so do download it and make sure it's ahead of all weblogic
stuff in the server's classpath (as it is created by the start script).
Joe
>
>
thank you
FOUND A JAVA LEVEL DEADLOCK:
"ExecuteThread: '180' for queue: 'default'":
waiting to lock monitor 0xcbb28 (object 0xdee1d070, a oracle.jdbc.driver.OraclePreparedStatement),
which is locked by "ExecuteThread: '73' for queue: 'default'"
"ExecuteThread: '73' for queue: 'default'":
waiting to lock monitor 0xcbc78 (object 0xdec416b8, a oracle.jdbc.driver.OracleConnection),
which is locked by "ExecuteThread: '180' for queue: 'default'"
JAVA STACK INFORMATION FOR THREADS LISTED ABOVE:
Java Stack for "ExecuteThread: '180' for queue: 'default'":
==========
at oracle.jdbc.driver.OraclePreparedStatement.sendBatch(OraclePreparedStatement.java:431)
at oracle.jdbc.driver.OracleConnection.commit(OracleConnection.java:838)
at weblogic.jdbc.jts.Connection.internalCommit(Connection.java:697)
at weblogic.jdbc.jts.Connection.commit(Connection.java:415)
at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:1180)
at weblogic.transaction.internal.ServerResourceInfo.commit(ServerResourceInfo.java:419)
at weblogic.transaction.internal.ServerSCInfo.startCommit(ServerSCInfo.java:233)
at weblogic.transaction.internal.ServerTransactionImpl.localCommit(ServerTransactionImpl.java:1397)
at weblogic.transaction.internal.ServerTransactionImpl.globalRetryCommit(ServerTransactionImpl.java:1940)
at weblogic.transaction.internal.ServerTransactionImpl.globalCommit(ServerTransactionImpl.java:1886)
at weblogic.transaction.internal.ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:221)
at weblogic.transaction.internal.ServerTransactionImpl.commit(ServerTransactionImpl.java:190)
at weblogic.ejb20.internal.BaseEJBObject.postInvoke(BaseEJBObject.java:231)
at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:46)
at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doGet(HttpRequestHandlerServlet.java:78)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Java Stack for "ExecuteThread: '73' for queue: 'default'":
==========
at oracle.jdbc.driver.OracleConnection.getDefaultRowPrefetch(OracleConnection.java:1263)
at oracle.jdbc.driver.OracleStatement.setFetchSize(OracleStatement.java:4878)
at weblogic.jdbc.common.internal.ConnectionEnv.cleanUpStatementForReUse(ConnectionEnv.java:747)
at weblogic.jdbc.common.internal.ConnectionEnv.dropStatement(ConnectionEnv.java:719)
at weblogic.jdbc.jts.Statement.close(Statement.java:231)
at weblogic.jdbc.rmi.internal.StatementImpl.close(StatementImpl.java:97)
at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:123)
at weblogic.jdbc.rmi.SerialStatement.close(SerialStatement.java:113)
at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseStatement(PersistenceManagerImpl.java:596)
at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:562)
at weblogic.ejb20.cmp11.rdbms.PersistenceManagerImpl.releaseResources(PersistenceManagerImpl.java:531)
at com.fourthpass.wpserver.billingentities.PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.ejbRemove(PendingBillingInfo_6hg1f2__WebLogic_CMP_RDBMS.java:1135)
at weblogic.ejb20.manager.DBManager.remove(DBManager.java:627)
at weblogic.ejb20.internal.EntityEJBObject.remove(EntityEJBObject.java:117)
at com.fourthpass.wpserver.billingentities.PendingBillingInfoBeanCMP_6hg1f2_EOImpl.remove(PendingBillingInfoBeanCMP_6hg1f2_EOImpl.java:559)
at com.fourthpass.wpserver.billing.BillingBean.movePendingToActiveBilling(BillingBean.java:1442)
at com.fourthpass.wpserver.billing.BillingBean.reportSuccessfulInstallation(BillingBean.java:1349)
at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:968)
at com.fourthpass.wpserver.billing.BillingBean.reportApplicationInstallStatusCode(BillingBean.java:937)
at com.fourthpass.wpserver.billing.BillingBean_t3moiz_EOImpl.reportApplicationInstallStatusCode(BillingBean_t3moiz_EOImpl.java:1265)
at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.handleOtaEvent(InstallNotifyCommand.java:187)
at com.fourthpass.wpserver.handlers.request.mascommands.InstallNotifyCommand.process(InstallNotifyCommand.java:94)
at com.fourthpass.wpserver.request.handlers.MASRequestHandler.process(MASRequestHandler.java:90)
at com.fourthpass.wpserver.request.RequestProcessorBean.processRequest(RequestProcessorBean.java:113)
at com.fourthpass.wpserver.request.RequestProcessorBean_p612k3_EOImpl.processRequest(RequestProcessorBean_p612k3_EOImpl.java:37)
at com.fourthpass.wpserver.handlers.deviceAdapter.AbstractDeviceHandler.processRequest(AbstractDeviceHandler.java:97)
at com.fourthpass.wpserver.irm.http.RequestHandler.process(RequestHandler.java:190)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doRequest(HttpRequestHandlerServlet.java:128)
at com.fourthpass.wpserver.irm.http.HttpRequestHandlerServlet.doPost(HttpRequestHandlerServlet.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2495)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2204)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
Found 1 deadlock.

Oracle jdbc driver: sort order between letters and numbers

Hello,
I am facing a very strange problem with sortering of data between letters and numbers.
I'am executing the following SQL request:
SELECT nummsg FROM CWD01 where nummsg = '00000001' or nummsg = 'AAAA0001' order by nummsg
When this request is executed with sqlplus or SQuirreL, I receive the expected result:
NUMMSG
00000001
AAAA0001
When I execute the following java code:
try { String className = "oracle.jdbc.driver.OracleDriver"; Class driverObject = Class.forName(className); Connection con = DriverManager.getConnection("myurl", "user", "pass"); Statement stmt = con.createStatement(); ResultSet rs = stmt.executeQuery( "SELECT nummsg FROM CWD01 where nummsg = '00000001' or nummsg = 'AAAA0001' order by nummsg"); while (rs.next()) { String x = rs.getString("nummsg"); System.out.println("nummsg " +x); } } catch (Exception e) { System.out.println("Failed: Driver Error: "+ e.getMessage()); }
I receive the unexpected result:
nummsg AAAA0001
nummsg 00000001
We are using the following version of Oracle:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi
and the following jdbc driver:
Oracle Database 10g Release 2 (10.2.0.1.0) JDBC Drivers (ojdbc14.jar (1,536,979 bytes) - classes for use with JDK 1.4 and 1.5)
Any suggestion?

I checked, I'am sure of the problem:
package test;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;
public class Test {
 public static void main(String[] args) {
 try {
 String className = "oracle.jdbc.driver.OracleDriver";
 Class driverObject = Class.forName(className);
 Connection con = DriverManager.getConnection("jdbc:oracle:thin:@<server>[:<1521>]:<database_name>", "user", "password");
 Statement stmt = con.createStatement();
 ResultSet rs = stmt.executeQuery(
 "SELECT nummsg FROM CWD01 where nummsg = '00000001' or nummsg = 'AAAA0001' order by nummsg");
 while (rs.next()) {
 String x = rs.getString("nummsg");
 System.out.println("nummsg " + x);
 } catch (Exception e) {
 System.out.println("Failed: Driver Error: " + e.getMessage());
}The table CWD01 defines the column NUMMSG as VARCHAR2(8).
The output gives:
nummsg AAAA0001
nummsg 00000001

Oracle / JDBC Error when Returning values from an Insert

I have a (oracle) table with a auto-incrementing id. From time to time I want to insert rows to this table, but want to be able to know what the pk of the newly inserted row is. One way I could do this is:
SQL> variable var1 number;
SQL> insert into test (name) values ('test value') returning id into :var1;
1 row created.
SQL> print var1;
13
As best as I can write it, that in java should be:
String query = "insert into test (name) values ('test') returning id into :var1";
OracleCallableStatement cs = (OracleCallableStatement) conn.prepareCall(query);
cs.registerOutParameter(1, OracleTypes.NUMBER );
cs.execute();
System.out.println(cs.getInt(1));
The problem is that when I run it, I get an error:
java.sql.SQLException: Protocol violation
     at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
     at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
     at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208)
     at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:764)
     at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:215)
     at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:954)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1168)
     at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3285)
     at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3390)
     at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4223)
     at restitution.shared.Sandbox2.run(Sandbox2.java:25)
     at restitution.shared.Sandbox2.main(Sandbox2.java:11)
According to their website, this is (yet another) bug:
What does "Protocol Violation" mean?
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.
Can someone tell me what I'm doing wrong? Is there any other ways to do a insert / get key in one sql query ?

I tried your solution, but it didn't work. I get an error (incorrect column number):
Caused by: java.sql.SQLException: Niepoprawny indeks kolumny
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:208)
at oracle.jdbc.driver.OracleCallableStatement.registerOutParameterInternal(OracleCallableStatement.java:121)
at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java:283)
at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java:363)
at (...).Row$1.createCallableStatement(Row.java:82)
at org.springframework.jdbc.core.JdbcTemplate.execute(JdbcTemplate.java:836)
... 69 more
The code is following:
                    String query = "BEGIN insert into movement (doc_number) values ('abc') returning id into :?; END;";
                    OracleCallableStatement cs = (OracleCallableStatement) c.prepareCall(query);
                    cs.registerOutParameter(1, OracleTypes.NUMBER);
                    cs.execute();
                    LOG.debug("result:"+ cs.getInt(1));
I used Oracle database 10.2.0.1 with jdbc thin driver ojdbc14.jar. Could you point out your configuration?
Regards,
Rafal Rusin
www.mimuw.edu.pl/~rrusin

XSU expecting oracle/jdbc/OracleConnection

Similar Messages

Maybe you are looking for