Oracle JDBC 10g - InitialLimit bug ?

'Lo everybody !
I'm testing OracleConnectionCacheManager and its InitialLimit parameter.
DOCUMENTATION:
http://download-west.oracle.com/docs/cd/B12037_01/java.101/b10979/conncache.htm
"InitialLimit:
Sets how many connections are created in the cache when it is created or reinitialized.
When this property is set to an integer value greater than 0,
creating or reinitializing the cache automatically creates the specified number of connections,
filling the cache in advance of need."
TESTING:
Setting InitialLimit=5 and MaxLimit=10: I can only get 5 connections.
Setting InitialLimit=10 and MaxLimit=10: I cannot get any connection.
Setting InitialLimit=0 and MaxLimit=10: I can get up to 10 connections.
Well, it seems that the InitialLimit connections are created BUT cannot be used at all !
Anybody can confirm this ?
Thanx.
Jean.

Hi,
Yes, I have the same experience.
I read the documentation many times and knew what their meanings , but got your result. Any suggestion ?

Similar Messages

Oracle JDBC (10g) reading clobs -- best practices

What is the better approach using oracle 10g to save clobs:
#1) This:
PreparedStatement pstmt = conn.prepareStatement
//Create the clob for insert
Clobs Clobs = new Clobs();
CLOB TempClob = Clobs.CreateTemporaryCachedCLOB(conn);
java.io.Writer writer = TempClob.getCharacterOutputStream();
writer.write(Description);
writer.flush();
writer.close();
#2) Or this:
OraclePreparedStatement pstmt = (OraclePreparedStatement)conn.prepareStatement
pstmt.setStringForClob()
According to my notes, it is #2.
What is the better approach to read clobs:
#1) Stream the clob
//Get character stream to retrieve clob data
Reader instream = ClobIn.getCharacterStream();
//Create temporary buffer for read
char[] buffer = new char[10];
//Length of characters read
int length = 0;
//Fetch data
while ((length = instream.read(buffer)) != -1){
for (int i=0; i<length; i++){
Contents += buffer;
//Close input stream
instream.close();
//Empty LOB
ClobIn.empty_lob();
#2) Or this:
Simply use rs.getString() to get your clob contents. This will return the entire clob and will not truncate.
Im just confused on the best practices for performance/memory allocation and I keep reading people saying different.
Reposted in JDBC forum

Check chapter 16 of "PL/SQL Programming", by Oracle Press, for a starter.
Then have a look at this link - I found it helpful: http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/files/advanced/LOBSample/LOBSample.java.html

Oracle JDBC Thin Driver

I am using CLOBS with the Oracle thin driver and am experiencing horrible performance. We need datavalues more than a VARCHAR2 and have used CLOB but the method Oracle uses to get the data in and out is super slow.
MS SQL Server JDBC with text is awesome and fast. But Oracle is slow and very cumbersome.
Help

We are using 9.0.2.
So what you are saying is although the column is CLOB
in Oracle 10 g we can use a normal result set
rset.getString( 1 ) no special oracle stuff just the
e Oracle thin driver for 10g?
Also this will retrieve a String greater than 4000
bytes?Exactly. Not only you can retieve a clob as string, you can also insert clob
as a string too. Here is the code I referred in last post in case you do not
have access to oracle ten network:
* @author Savitha
* @version 1.0
* Development Environment : Oracle JDeveloper 10g
* Name of the Application : ClobManipulationIn10g.java
* Creation/Modification History :
* Savitha 17-Mar-2004 Created.
package oracle.otnsamples.jdbc;
// Java SQL classes
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
// Oracle JDBC driver class
import oracle.jdbc.OracleDriver;
// Java IO classes
import java.io.IOException;
import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
//Java Util classes
import java.util.Properties;
* This class demonstrates the Oracle JDBC 10g enhanced features for inserting
* and retrieving CLOB data from the database. Using the new features, large
* data of more than 32765 bytes can be inserted into the database using the
* existing PreparedStatement.setString() and PreparedStatement.getString()
* methods.
public class ClobManipulationIn10g {
/* Database Connection object */
private Connection conn = null;
/* Variables to hold database details */
private String url = null;
private String user = null;
private String password = null;
// Create a property object to hold the username, password and
// the new property SetBigStringTryClob.
private Properties props = new Properties();
/* String to hold file name */
private String fileName = null;
* Default Constructor to instantiate and get a handle to class methods
* and variables.
public ClobManipulationIn10g(String fileName) {
this.fileName = fileName;
* Main runnable class.
public static void main(String[] args) throws SQLException {
// Instantiate the main class.
ClobManipulationIn10g clobManipulationIn10g =
new ClobManipulationIn10g(args[0]);
// Load the Oracle JDBC driver class.
DriverManager.registerDriver(new OracleDriver());
// Load the database details into the variables.
String dbUrl = "jdbc:oracle:thin:@<database host machine>:<port>:<SID>";
clobManipulationIn10g.url = dbUrl;
// Replace the username where the table 'clob_tab' was created.
clobManipulationIn10g.user = "scott";
// Replace the password of the username.
clobManipulationIn10g.password = "tiger";
// Populate the property object to hold the username, password and
// the new property 'SetBigStringTryClob' which is set to true. Setting
// this property allows inserting of large data using the existing
// setString() method, to a CLOB column in the database.
clobManipulationIn10g.props.put("user", clobManipulationIn10g.user );
clobManipulationIn10g.props.put("password", clobManipulationIn10g.password);
clobManipulationIn10g.props.put("SetBigStringTryClob", "true");
// Check if the table 'CLOB_TAB' is present in the database.
clobManipulationIn10g.checkTables();
// Call the methods to insert and select CLOB from the database.
clobManipulationIn10g.insertClob();
clobManipulationIn10g.selectClob();
* This method will insert the data into a CLOB column in the database.
* Oracle JDBC 10g has enhanced the existing PreparedStatement.setString()
* method for setting the data more than 32765 bytes. So, using setString(),
* it is now easy to insert CLOB data into the database directly.
private void insertClob() throws SQLException {
// Create a PreparedStatement object.
PreparedStatement pstmt = null;
try {
// Create the database connection, if it is closed.
if ((conn==null)||conn.isClosed()){
// Connect to the database.
conn = DriverManager.getConnection( this.url, this.props );
// Create SQL query to insert data into the CLOB column in the database.
String sql = "INSERT INTO clob_tab VALUES(?)";
// Read a big file(larger than 32765 bytes)
String str = this.readFile();
// Create the OraclePreparedStatement object
pstmt = conn.prepareStatement(sql);
// Use the same setString() method which is enhanced to insert
// the CLOB data. The string data is automatically transformed into a
// clob and inserted into the database column. Make sure that the
// Connection property - 'SetBigStringTryClob' is set to true for
// the insert to happen.
pstmt.setString(1,str);
// Execute the PreparedStatement
pstmt.executeUpdate();
} catch (SQLException sqlex) {
// Catch Exceptions and display messages accordingly.
System.out.println("SQLException while connecting and inserting into " +
"the database table: " + sqlex.toString());
} catch (Exception ex) {
System.out.println("Exception while connecting and inserting into the" +
" database table: " + ex.toString());
} finally {
// Close the Statement and the connection objects.
if (pstmt!=null) pstmt.close();
if (conn!=null) conn.close();
* This method reads the CLOB data from the database by using getString()
* method.
private void selectClob() throws SQLException {
// Create a PreparedStatement object
PreparedStatement pstmt = null;
// Create a ResultSet to hold the records retrieved.
ResultSet rset = null;
try {
// Create the database connection, if it is closed.
if ((conn==null)||conn.isClosed()){
// Connect to the database.
conn = DriverManager.getConnection( this.url, this.props );
// Create SQL query statement to retrieve records having CLOB data from
// the database.
String sqlCall = "SELECT clob_col FROM clob_tab";
pstmt= conn.prepareStatement(sqlCall);
// Execute the PrepareStatement
rset = pstmt.executeQuery();
String clobVal = null;
// Get the CLOB value from the resultset
while (rset.next()) {
clobVal = rset.getString(1);
System.out.println("CLOB length: "+clobVal.length());
} catch (SQLException sqlex) {
// Catch Exceptions and display messages accordingly.
System.out.println("SQLException while connecting and querying the " +
"database table: " + sqlex.toString());
} catch (Exception ex) {
System.out.println("Exception while connecting and querying the " +
"database table: " + ex.toString());
} finally {
// Close the resultset, statement and the connection objects.
if (rset !=null) rset.close();
if (pstmt!=null) pstmt.close();
if (conn!=null) conn.close();
* Method to check if the table ('CLOB_TAB') exists in the database; if not
* then it is created.
* Table Name: CLOB_TAB
* Column Name Type
* col_col CLOB
private void checkTables() {
Statement stmt = null;
ResultSet rset = null;
try {
// Create the database connection, if it is closed.
if ((conn==null)||conn.isClosed()){
// Connect to the database.
conn = DriverManager.getConnection( this.url, this.props );
// Create Statement object
stmt = conn.createStatement();
// Check if the table is present
rset = stmt.executeQuery(" SELECT table_name FROM user_tables "+
" WHERE table_name = 'CLOB_TAB' ");
// If the table is not present, then create the table.
if (!rset.next()) {
// Table does not exist, create it
stmt.executeUpdate(" CREATE TABLE clob_tab(clob_col CLOB)");
} catch (SQLException sqlEx) {
System.out.println("Could not create table clob_tab : "
+sqlEx.toString());
} finally {
try {
if( rset != null ) rset.close();
if( stmt != null ) stmt.close();
if (conn!=null) conn.close();
} catch(SQLException ex) {
System.out.println("Could not close objects in checkTables method : "
+ex.toString());
* This method reads the specified text file and, returns the content
* as a string.
private String readFile()
throws FileNotFoundException, IOException{
// Read the file whose content has to be passed as String
BufferedReader br = new BufferedReader(new FileReader(fileName));
String nextLine = "";
StringBuffer sb = new StringBuffer();
while ((nextLine = br.readLine()) != null) {
sb.append(nextLine);
// Convert the content into to a string
String clobData = sb.toString();
// Return the data.
return clobData;
}

Bug in Oracle JDBC Pooling Classes - Deadlock

We are utilizing Oracle's connection caching (drivers 10.2.0.1) and have found a deadlock situation. I reviewed the code for the (drivers 10.2.0.3) and I see the same problem could happen.
I searched and have not found this problem identified anywhere. Is this something I should post to Oracle in some way (i.e. Metalink?) or is there a better forum to get this resolved?
We are utilizing an OCI driver with the following setup in the server.xml
<ResourceParams name="cmf_toolbox">
<parameter>
<name>factory</name>
<value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>user</name>
<value>hidden</value>
</parameter>
<parameter>
<name>password</name>
<value>hidden</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:oci:@PTB2</value>
</parameter>
<parameter>
<name>connectionCachingEnabled</name>
<value>true</value>
</parameter>
<parameter>
<name>connectionCacheProperties</name>
<value>(InitialLimit=5,MinLimit=15,MaxLimit=75,ConnectionWaitTimeout=30,InactivityTimeout=300,AbandonedConnectionTimeout=300,ValidateConnection=false)</value>
</parameter>
</ResourceParams>
We get a deadlock situation between two threads and the exact steps are this:
1) thread1 - The OracleImplicitConnectionClassThread class is executing the runAbandonedTimeout method which will lock the OracleImplicitConnectionCache class with a synchronized block. It will then go thru additional steps and finally try to call the LogicalConnection.close method which is already locked by thread2
2) thread2 - This thread is doing a standard .close() on the Logical Connection and when it does this it obtains a lock on the LogicalConnection class. This thread then goes through additional steps till it gets to a point in the OracleImplicitConnectionCache class where it executes the reusePooledConnection method. This method is synchronized.
Actual steps that cause deadlock:
1) thread1 locks OracleImplicitConnectionClass in runAbandonedTimeout method
2) thread2 locks LogicalConnection class in close function.
3) thread1 tries to lock the LogicalConnection and is unable to do this, waits for lock
4) thread2 tries to lock the OracleImplicitConnectionClass and waits for lock.
***DEADLOCK***
Thread Dumps from two threads listed above
thread1
Thread Name : Thread-1 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x30267fe8 Waiting for Monitor Lock on 0x509190d8 Java Stack at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - waiting to lock 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at oracle.jdbc.pool.OracleImplicitConnectionCache.closeCheckedOutConnection(OracleImplicitConnectionCache.java:1330) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.runAbandonedTimeout(OracleImplicitConnectionCacheThread.java:261) - locked 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.run(OracleImplicitConnectionCacheThread.java:81)
thread2
Thread Name : http-7320-Processor83 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x509190d8 Waiting for Monitor Lock on 0x30267fe8 Java Stack at oracle.jdbc.pool.OracleImplicitConnectionCache.reusePooledConnection(OracleImplicitConnectionCache.java:1608) - waiting to lock 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleConnectionCacheEventListener.connectionClosed(OracleConnectionCacheEventListener.java:71) - locked 0x34d514f8> (a oracle.jdbc.pool.OracleConnectionCacheEventListener) at oracle.jdbc.pool.OraclePooledConnection.callImplicitCacheListener(OraclePooledConnection.java:544) at oracle.jdbc.pool.OraclePooledConnection.logicalCloseForImplicitConnectionCache(OraclePooledConnection.java:459) at oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:475) at oracle.jdbc.driver.LogicalConnection.closeInternal(LogicalConnection.java:243) at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - locked 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at com.schoolspecialty.cmf.yantra.OrderDB.updateOrder(OrderDB.java:2022) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:119) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:67) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.UpdateCartAction.perform(Unknown Source) at com.schoolspecialty.mvc2.ActionServlet.doPost(ActionServlet.java:112) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPostOrGet(Unknown Source) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at com.schoolspecialty.ecommerce.servlets.filters.EcommerceURLFilter.doFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)

We used a documented option to abandon connects in the case of an unforeseen error. The consequence of using this option was not a graceful degradation in performance but a complete lockup of the application. The scenario in which we created a moderate number of abandoned connections was a rare error scenario but a valid test.
How could this not be a bug in the Oracle driver? Is dead-lock a desireable outcome of using an option? Is dead-lock ever an acceptable consequence of using a feature as documented?
Turns out other Oracle options to recover from an unexpected error also incur a similar deadlock (TimeToLiveTimeout).
I did a code review of the decompiled drivers and it clearly shows the issue, confirming the original report of this issue. Perhaps you have evidence to the contrary or better evidence to support your statement "not a bug in Oracle"?
Perhaps you are one of the very few people who have not experience problems with Oracle drivers? I've been using Oracle since 7.3.4 and it seems that I have always been working around Oracle JDBC driver problems.
We are using Tomcat with the OracleDataSourceFactory.

Important--Bug(ORA-22813) fixes in Oracle Database 10g Release 10.2.0.4

Hi,
I found that in SELECT STATEMENTs where we use "xmlagg() functions with a GROUP BY/ORDER BY,it fails with ORA-22813 if the result is too large.
This happens as there is a hard coded limit on the result size. (max 30k)
Next,i confirmed that and when i removed a portion of the XML agg() values and executed it---Wonders,it runs perfectly fine.
This means that ""xmlagg() functions with a GROUP BY/ORDER BY,fails with ORA-22813 since the result is too large.
I have come to know that patch "Release 10.2.0.4" has the fix for Bug-22813 for "xmlagg() functions with a GROUP BY/ORDER BY".
Could you all please confirm that "Oracle Database 10g Release 10.2.0.4" (patch 10.2.04) fixes the issue?
Based on your confirmation,i can go ahead to get the patch installed.
Current Version:-Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
Thanks
Mainak

Your query should be written something like this..
select d.*
from fbnk_customer,
       XMLTABLE
          '//c3'
          passing XMLRECORD
          columns
          C3_VALUE varchar2(60) path 'text()'
       ) d
where recid='1001400'; Although it would be better to use an extact path expression rather than '//c3'

Bug in Oracle JDBC thin driver (parameter order)

[ I'd preferably send this to some Oracle support email but I
can't find any on both www.oracle.com and www.technet.com. ]
The following program illustrates bug I found in JDBC Oracle thin
driver.
* Synopsis:
The parameters of prepared statement (I tested SELECT's and
UPDATE's) are bound in the reverse order.
If one do:
PreparedStatement p = connection.prepareStatement(
"SELECT field FROM table WHERE first = ? and second = ?");
and then bind parameter 1 to "a" and parameter to "b":
p.setString(1, "a");
p.setString(2, "b");
then executing p yields the same results as executing
SELECT field FROM table WHERE first = "b" and second = "a"
although it should be equivalent to
SELECT field FROM table WHERE first = "a" and second = "b"
The bug is present only in "thin" Oracle JDBC driver. Changing
driver to "oci8" solves the problem.
* Version and platform info:
I detected the bug using Oracle 8.0.5 server for Linux.
According to $ORACLE_HOME/jdbc/README.doc that is
Oracle JDBC Drivers release 8.0.5.0.0 (Production Release)
* The program below:
The program below illustrates the bug by creating dummy two
column table, inserting the row into it and then selecting
the contents using prepared statement. Those operations
are performed on both good (oci8) and bad (thin) connections,
the results can be compared.
You may need to change SID, listener port and account data
in getConnecton calls.
Sample program output:
$ javac ShowBug.java; java ShowBug
Output for both connections should be the same
--------------- thin Driver ---------------
[ Non parametrized query: ]
aaa
[ The same - parametrized (should give one row): ]
[ The same - with buggy reversed order (should give no answers):
aaa
--------------- oci8 driver ---------------
[ Non parametrized query: ]
aaa
[ The same - parametrized (should give one row): ]
aaa
[ The same - with buggy reversed order (should give no answers):
--------------- The end ---------------
* The program itself
import java.sql.*;
class ShowBug
public static void main (String args [])
throws SQLException
// Load the Oracle JDBC driver
DriverManager.registerDriver(new
oracle.jdbc.driver.OracleDriver());
System.out.println("Output for both connections should be the
same");
Connection buggyConnection
= DriverManager.getConnection
("jdbc:oracle:thin:@localhost:1521:ORACLE",
"scott", "tiger");
process("thin Driver", buggyConnection);
Connection goodConnection
= DriverManager.getConnection ("jdbc:oracle:oci8:",
"scott", "tiger");
process("oci8 driver", goodConnection);
System.out.println("--------------- The end ---------------");
public static void process(String title, Connection conn)
throws SQLException
System.out.println("--------------- " + title + "
Statement stmt = conn.createStatement ();
stmt.execute(
"CREATE TABLE bug (id VARCHAR(10), val VARCHAR(10))");
stmt.executeUpdate(
"INSERT INTO bug VALUES('aaa', 'bbb')");
System.out.println("[ Non parametrized query: ]");
ResultSet rset = stmt.executeQuery(
"select id from bug where id = 'aaa' and val = 'bbb'");
while (rset.next ())
System.out.println (rset.getString (1));
System.out.println("[ The same - parametrized (should give one
row): ]");
PreparedStatement prep = conn.prepareStatement(
"select id from bug where id = ? and val = ?");
prep.setString(1, "aaa");
prep.setString(2, "bbb");
rset = prep.executeQuery();
while (rset.next ())
System.out.println (rset.getString (1));
System.out.println("[ The same - with buggy reversed order
(should give no answers): ]");
prep = conn.prepareStatement(
"select id from bug where id = ? and val = ?");
prep.setString(1, "bbb");
prep.setString(2, "aaa");
rset = prep.executeQuery();
while (rset.next ())
System.out.println (rset.getString (1));
stmt.execute("DROP TABLE bug");
null

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Bug in Oracle JDBC Driver: NullPointerException when calling clearParameters

There is a bug in the latest version of the JDBC driver that throws a NPE when calling PreparedStatement.clearParameters(). I don't need a response to this, since I have a workaround (just catching and ignoring the exception), but it should probably be fixed. I speculate that the problem only occurs when you try to call clearParameters() more than once on the same PS, but I haven't confirmed it.
It is probably an easy fix. Following is the stack trace:
java.lang.NullPointerException
at oracle.jdbc.dbaccess.DBData.clearItem(DBData.java:431)
at oracle.jdbc.dbaccess.DBDataSetImpl.clearItem(DBDataSetImpl.java:3528)
at oracle.jdbc.driver.OraclePreparedStatement.clearParameters(OraclePreparedStatement.java:3401)
at com.solarmetric.datasource.PreparedStatementCache$CachePreparedStatement.close(PreparedStatementCache.java:293)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedStatementBatch(SQLExecutionManagerImpl.java:666)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedStatement(SQLExecutionManagerImpl.java:514)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeInternal(SQLExecutionManagerImpl.java:406)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.flush(SQLExecutionManagerImpl.java:273)
at com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.flush(JDBCStoreManager.java:421)
at com.solarmetric.kodo.runtime.PersistenceManagerImpl.flush(PersistenceManagerImpl.java:549)
at com.solarmetric.kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:412)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.testMakePersistentAssignsObjectId2(Unknown Source)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.testMakePersistentAssignsObjectId(Unknown Source)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.runTest(Unknown Source)
at com.sun.jdotck.api.persistencemanager.PersistenceManagerTest.run(Unknown Source)
at com.solarmetric.kodo.compatibility.JDOCompatabilityTestSuite$1.runTest(JDOCompatabilityTestSuite.java:493)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:524)
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Take a look at the method that is causing the NullPointerException:
public void clearItem(int i)
if (!m_dynamic && m_vector == null && i < m_vector.size())
m_vector.removeElementAt(i);
if (m_items != null && i >= m_items.length)
return;
m_items[i] = null;
return;
A NullPointerException will be thrown whenever clearParameters() is called when no parameters have yet been bound.
The first IF statement should read:
if (!m_dynamic && m_vector != null && i < m_vector.size())
A simple workaround would be to make sure that your parameter list is never empty before calling clearParameters(). Is there a patch for this anywhere?

Bug in Oracle JDBC thin driver 8.1.6 ?

Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Oracle Database 10g JDBC Samples on OTN

Review the OTN's new Oracle Database 10g JDBC Samples that illustrate new features introduced with Oracle10g JDBC Driver. The features illustrated are Connection Cache, Named Parameter Support, IEEE Datatypes, Thin Driver support for PLSQL Index by Tables and Web Rowset. Also watch out for samples on Datalinks, New Encryption Algorithms, Globalization Support, Shortcuts for CLOB manipulation and more to be hosted shortly.
The samples are available at,
http://otn.oracle.com/sample_code/tech/java/sqlj_jdbc/files/oracle10g/index.html

I suppose that is nice.
It would be even nicer if the drivers actually conformed to JDBC so that one could for example reliably use blobs in a J2EE server with CMP.

Consolidation of Oracle Database 10g Express Edition "Bugs"

I'll take a stab at cleaning this up. This is a collection of postings, reported as bugs, but not really bugs or difficult to understand/reproduce. These were filed in the Database General forum and they should have been filed in the XE forum.
Firstly, thank you for taking the time to report these issues and suspected issues. In the future, it would be quite helpful to everyone if you reported these in the XE forum.
1. Oracle Database 10g Express Edition Bugs
This is not a bug. The developer toolbar will show when you are authenticated to the development environment. You do not have to be authenticated to your application for the developer toolbar to appear.
2. Oracle Database 10g Express Edition Bugs
If data is present in the cache, this is up to the application developer (you) to implement the proper security which prevents this behavior.
3. Oracle Database 10g Express Edition Bugs
This is a minor issue, at best. For this type of search interface, it is desirable to perform a case-insensitive query. Wouldn't it be a shame if you searched for "item" and it did not return results that contained "Item".
4. Oracle Database 10g Express Edition Bugs
This is not a bug. Different authentication schemes have different data restrictions. It is up to you, the application developer, to easily implement the data validations appropriate for your application.
5. Oracle Database 10g Express Edition Bugs
Insufficient information provided. You will have to specify what exact error message is arising and what data you changed which resulted in this error. A complete step-by-step test case is desirable, please.
6. Oracle Database 10g Express Edition Bugs
Duplicate of #5 above. And still insufficient information.
7. Oracle Database 10g Express Edition Bugs
Not a bug. This is intentional behavior. If I know I want to enter table name EMP, it would be bad from a usability standpoint to always force the user to employ their mouse.
8. Oracle Database 10g Express Edition Bugs
This could not be reproduced.
9. Oracle Database 10g Express Edition Bugs
Almost identical to #8. Please clarify what the expected behavior should be.
Joel

This discussion has been continued in the XE forum at:
Consolidation of Oracle Database 10g Express Edition "Bugs"
In the future, please attempt to post all XE-related issues in the XE forum.
Joel

Bug in Oracle JDBC Drivers with {ts ?}

Oracle fails to set bind variables correctly when using the {ts ?} in an insert. It works ok if you use {d ?}.
Ex:
String st = "INSERT INTO BL(NM,TSTAMP) VALUES (?,{ts ?} )";
System.out.println(dbConn.nativeSQL(st));
java.sql.PreparedStatement stmt = dbConnn.prepareStatement(st);
stmt.setString(1,"test");
stmt.setString(2,"2000-08-18 09:33:45");
int xx = stmt.executeUpdate();
Oracle Reports:
INSERT INTO BL (NM,TSTAMP) VALUES (:1,TO_DATE (?, 'YYYY-MM-DD HH24:MI:SS'))
ConnectionPoolManager failed:java.sql.SQLException: ORA-00911: invalid character
Notice the ? doesn't change to :2.
Whoops.
Also when does Oracle plan to implement {fn }
scalars. There are work arounds but they are not portable. If not soon we will switch our suggested database for our clients.
null

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Oracle JDBC 8.1.7 XA prepare bug

Both Oracle JDBC 8.1.7 XA thin and oci drivers have a bug related to
the prepare fase of 2PC.
In some circunstances when loosing connection, the prepare fase cannot
be completed
but Oracle driver returns a successfull status, so WLS issues second
phase of commit
when it shouldn't. This is a known bug on Oracle.
Josep Blazquez.

http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html
Btw: the Oracle homepage does have a search function which will find that page using "download jdbc driver" as the search criteria.

Does Oracle XE 10g or 11g have supported patches/bug fixes

Does Oracle XE 10g or 11g have supported patches/bug fixes?

XE isn't patch-able, unfortunately- eg. in the section ...Major Features Not Included at http://docs.oracle.com/cd/E17781_01/license.112/e18068/toc.htm#XELIC116 a "patch set" is one of the "not included" items
One could install one of the full release editions, get it patched, and upgrade an XE instance with the patch-able edition, but access to patches requires a support agreement.

Oracle JDBC driver 10g and xMII

I have a BLS that tries inserting CLOB data into Oracle 10g database. Since Oracle 8 JDBC driver does not support that (I saw other SDN messages on the same issue), I have download and copied Oracle JDBC driver for 10g
ojdbc14.jar to
C:\ServletExec AS\se-xMII\webapps\default\Lighthammer\WEB-INF\lib
folder
I restarted Servlet exec engine and I'm still seeing the same error
that the value to be inserted is too large ( I'm inserting more than
4000 characters but much lesser than 4 GB which CLOB column can take)
1. I want to understand if there is something else that I need to
change in order for xMII to pickup the new driver.
2. Also, should I add it classpath?
3. Looking at some Oracle notes on using capability of 10g driver for
manipulating large data, the property SetBigStringTryClob=true should
be set. I saw examples of some non-xMII applications setting it in their
servers.xml. Similarly, in which file can I set this property in xMII
to force the driver to use this feature?
Is ServerDefaults.xml under C:\Lighthammer\Illuminator\SysConf the
right place? Since it is not recommended to modify the configuration
files manually rather than using admin console, I'm not sure on this
one.
Let me know
Thanks

Are you really sure this "SetBig.." thing is the solution?
Searching for the ORA error you posted results in quite a few solutions in the way you write your SQL statement.
Maybe changing your statement might help.
If you don't mind can you post the SQL statement?
Another good test would be to see if the SQL statement goes through without any errors when used from a different SQL editor.I would suggest do that first if you haven't already.

Weblogic 5.1 and Oracle Database 10g JDBC Drivers

I need to know if there are JDBC drivers for Oracle Database 10g compatible with Weblogic Server 5.1.
Regards,
Luis

Hi. You should be able to use any JDBC driver with WebLogic 5.1.
It may be the JVM that complains, if you use too old a JVM...
Joe Weinstein at BEA Systems

Oracle JDBC 10g - InitialLimit bug ?

Similar Messages

Maybe you are looking for