Bug in oracle jdbc faq

The faq uses oracle.jdbc.V8Compatibility as a connection property, but the correct is oracle.jdbc.V8Compatible

Hi Paal,
Thanks for the feedback, and apologies for the delay responding to you.
Can you please confirm if this issue relates to the Documentation related faq at http://otn.oracle.com/contact/htdocs/faqs#documentation
This particular forum relates only to issues with the Online Documentation pages at: http://otn.oracle.com/documentation/index.html
If your feedback concerns other pages, please try another forum.
Thanks and regards,
Les

Similar Messages

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

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

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.

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?

Is it a bug for Oracle JDBC driver?

Hi,
I use the thin JDBC driver to connect my server, and try to obtain the meta data for the query data set. However, every time I issue 'getMetaData()' to get meta data, the following error is reported:
java.lang.NumberFormatException: For input string: "4294967295"
     at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
     at java.lang.Integer.parseInt(Integer.java:480)
     at java.lang.Integer.parseInt(Integer.java:518)
     at oracle.jdbc.driver.OracleResultSetMetaData.getPrecision(OracleResultSetMetaData.java:381)
     at genentity.GenEntityForm.getTableMetaData(GenEntityForm.java:445)
     at genentity.GenEntityForm.jButton2_actionPerformed(GenEntityForm.java:336)
and the program coding for this error is as follows:
sql = "SELECT * FROM " + tableName;
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
rsmd = rs.getMetaData(); <-- Error occurs in here.
Does anyone get an idea for this? Please help.
Thanks in advance,
Athens Yan.

Hi,
If u have applied the patch then there shud be no problem...try applying the patch again.

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.

Oracle JDBC driver does not handle Java empty strings correctly

If you store a Java empty string in a VARCHAR column, then try to retrieve it,
you get back a null.
Can someone from Oracle JDBC development
explain why this is not a bug? An empty
string is not the same as a null.

Hello!
Although all together different, but DATE type also behaves same way.
inserting createdate = NULL in database returns you blank on select query
inserting createdate= '' returns null on select. Correct me if i am wrong.
prity
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Nagaraj Govindaraj ([email protected]):
If you store a Java empty string in a VARCHAR column, then try to retrieve it,
you get back a null.
Can someone from Oracle JDBC development
explain why this is not a bug? An empty
string is not the same as a null.<HR></BLOCKQUOTE>
null

Help - Could not load 'oracle.jdbc.driver.OracleDriver ...

I'm using oci8 to connect to the Oracle database.
URL: jdbc:oracle:oci8:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(PORT=1527)(HOST=testhost)))(CONNECT_DATA=(SID=fnoe2pa)))
When I tried to start the weblogic server, I got the following errors:
Can you suggest what I should do next (step-wise)??? Thanks, Bobby
<Sleeping in createResource()>
####<15/08/2002 14:09:43> <Error> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001060> <Cannot startup connection pool
"pool/test_myapp" weblogic.common.ResourceException:
Could not load 'oracle.jdbc.driver.OracleDriver
If this is a type-4 JDBC driver, it could occur if the JDBC
driver is not in the system CLASSPATH.
If this is a type-2 JDBC driver, it may also indicate that
the Driver native layers(DBMS client lib or driver DLL)
have not been installed properly on your system
or in your PATH environment variable.
This is most likely caused by one of the following:
1. The native layer SO, SL, or DLL could not be found.
2. The file permissions on the native layer SO, SL, or DLL
have not been set properly.
3. The native layer SO, SL, or DLL exists, but is either
invalid or corrupted.
For more information, read the installation documentation
for your JDBC Driver, available from:
http://e-docs.bea.com
     at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection(ConnectionEnvFactory.java:212)
     at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:134)
     at weblogic.common.internal.ResourceAllocator.makeResources(ResourceAllocator.java:705)
     at weblogic.common.internal.ResourceAllocator.<init>(ResourceAllocator.java:282)
     at weblogic.jdbc.common.internal.ConnectionPool.startup(ConnectionPool.java:650)
     at weblogic.jdbc.common.JDBCService.addDeployment(JDBCService.java:107)
     at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:360)
     at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:285)
     at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:239)
     at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:199)
     at java.lang.reflect.Method.invoke(Native Method)
     at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
     at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
     at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:360)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
     at $Proxy31.updateDeployments(Unknown Source)
     at weblogic.management.configuration.ServerMBean_CachingStub.updateDeployments(ServerMBean_CachingStub.java:2977)
     at weblogic.management.mbeans.custom.ApplicationManager.startConfigManager(ApplicationManager.java:372)
     at weblogic.management.mbeans.custom.ApplicationManager.start(ApplicationManager.java:160)
     at java.lang.reflect.Method.invoke(Native Method)
     at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
     at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
     at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:360)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
     at $Proxy42.start(Unknown Source)
     at weblogic.management.configuration.ApplicationManagerMBean_CachingStub.start(ApplicationManagerMBean_CachingStub.java:480)
     at weblogic.management.Admin.startApplicationManager(Admin.java:1234)
     at weblogic.management.Admin.finish(Admin.java:644)
     at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:524)
     at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:207)
     at weblogic.Server.main(Server.java:35)
>
####<15/08/2002 14:09:43> <Info> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001082> <Creating Data Source named
jdbc/test_myapp for pool pool/test_myapp>
####<15/08/2002 14:09:43> <Info> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001070> <Checking existence of connection pool
pool/test_myapp requested by user system>
####<15/08/2002 14:09:43> <Error> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001059> <Error during Data Source creation:
weblogic.common.ResourceException: DataSource(jdbc/test_myapp) can't
be created with non-existent Pool (connection or multi)
(pool/test_myapp)>
####<15/08/2002 14:09:50> <Info> <EJB> <qawebmethods> <myserver>
<main> <system> <> <010008> <EJB Deploying file: myapp-ejb.jar>
####<15/08/2002 14:09:50> <Warning> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160007> <You are running WebLogic Server with J2EE
1.3 features enabled. The implementation of specific J2EE 1.3 features
(EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0)
in BEA WebLogic Server 6.1 is of a non-final version of the
appropriate specification. It is subject to change in future releases
once the specification becomes finalized. This may cause application
code developed for BEA WebLogic Server 6.1 that uses the new features
of J2EE 1.3 to be incompatible with the J2EE 1.3 platform supported in
future releases of BEA WebLogic Server.>
####<15/08/2002 14:09:59> <Error> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160001> <Error deploying application myapp-ejb:
Unable to deploy EJB: Counter from myapp-ejb.jar:
The DataSource with the JNDI name: jdbc/test_myapp could not be
located. Please ensure that the DataSource has been deployed
successfully and that the JNDI name in your EJB Deployment descriptor
is correct.
>
####<15/08/2002 14:09:59> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101053> <[HTTP myserver] Loading web app: myapp>
####<15/08/2002 14:09:59> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101059> <[myserver] Loading myapp from WAR file:
C:\bea\wlserver6.1\.\config\mydomain\applications\.wlnotdelete\wlap31483\myapp.war>
####<15/08/2002 14:09:59> <Warning> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160007> <You are running WebLogic Server with J2EE
1.3 features enabled. The implementation of specific J2EE 1.3 features
(EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0)
in BEA WebLogic Server 6.1 is of a non-final version of the
appropriate specification. It is subject to change in future releases
once the specification becomes finalized. This may cause application
code developed for BEA WebLogic Server 6.1 that uses the new features
of J2EE 1.3 to be incompatible with the J2EE 1.3 platform supported in
future releases of BEA WebLogic Server.>
####<15/08/2002 14:09:59> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101031>
<[WebAppServletContext(1412030,myapp,/myapp)] extracting classfiles to
C:\bea\wlserver6.1\config\mydomain\applications\.wlnotdelete\wlap31483\WEB-INF\_tmp_war_myapp:>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101032>
<[WebAppServletContext(1412030,myapp,/myapp)] extracted classfiles
successfully...>
####<15/08/2002 14:10:04> <Info> <HTTP Session> <qawebmethods>
<myserver> <main> <system> <> <100037> <Creating SessionContext of
type: memory for webapp: /myapp>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering classpath
servlet with initArgs 'null'>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering getior
servlet with initArgs 'null'>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering tunneling
servlets with initArgs 'wl-dispatch-policy=direct'>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering JSPServlet
with initArgs '[JspConfig:
verbose=true,packagePrefix=jsp_servlet,-compiler=javac,compileFlags=,workingDir=C:\bea\wlserver6.1\config\mydomain\applications\.wlnotdelete\wlap31483\WEB-INF\_tmp_war_myapp,pageCheckSeconds=1,superclass=null,keepgenerated=false,precompileContinue=false,compilerSupportsEncoding=true,encoding=null,defaultfilename=index.jsp,compilerclass=null,noTryBlocks=false]'>
####<15/08/2002 14:10:04> <Debug> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101097> <Registering ServletContext:
"myapp:/myapp">
####<15/08/2002 14:10:04> <Info> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160003> <Deployed : myapp>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101133> <Initializing WEB server myserver>
####<15/08/2002 14:10:04> <Notice> <Management> <qawebmethods>
<myserver> <main> <system> <> <141052> <Application Poller started for
development server.>
####<15/08/2002 14:10:04> <Notice> <WebLogicServer> <qawebmethods>
<myserver> <ListenThread> <system> <> <000202> <ListenThread listening
on port 7001>
####<15/08/2002 14:10:04> <Info> <NT Performance Pack> <qawebmethods>
<myserver> <ListenThread> <system> <> <000000> <NATIVE: NTSocketMuxer
was built on Nov 1 2001 16:39:28
>
####<15/08/2002 14:10:04> <Notice> <WebLogicServer> <qawebmethods>
<myserver> <SSLListenThread> <system> <> <000202> <SSLListenThread
listening on port 7002>
####<15/08/2002 14:10:05> <Notice> <Management> <qawebmethods>
<myserver> <main> <system> <> <141030> <Starting discovery of Managed
Server... This feature is on by default, you may turn this off by
passing -Dweblogic.management.discover=false>
####<15/08/2002 14:10:05> <Notice> <WebLogicServer> <qawebmethods>
<myserver> <main> <system> <> <000331> <Started WebLogic Admin Server
"myserver" for domain "mydomain" running in Development Mode>
####<15/08/2002 14:10:11> <Info> <NT Performance Pack> <qawebmethods>
<myserver> <ExecuteThread: '14' for queue: 'default'> <> <> <000000>
<Allocating: '2' NT reader threads>
####<15/08/2002 14:10:13> <Info> <HTTP> <qawebmethods> <myserver>
<ExecuteThread: '1' for queue: '__weblogic_admin_html_queue'> <system>
<> <101047> <[WebAppServletContext(5367844,console,/console)] actions:
init>
####<15/08/2002 14:10:18> <Info> <HTTP> <qawebmethods> <myserver>
<ExecuteThread: '1' for queue: '__weblogic_admin_html_queue'> <system>
<> <101047> <[WebAppServletContext(5367844,console,/console)]
FileServlet: init>
####<15/08/2002 14:10:18> <Info> <HTTP> <qawebmethods> <myserver>
<ExecuteThread: '1' for queue: '__weblogic_admin_html_queue'> <system>
<> <101047> <[WebAppServletContext(5367844,console,/console)]
FileServlet: Using standard I/O>

"thorick" <[email protected]> wrote in message news:<[email protected]>...
Most likely, the OCI libraries could not be loaded.
Before continuing down this path, is there any reason
why you want to use an OCI based Driver as opposed to the
all Java Oracle thin driver ?There is indeed a valid reason for my choice.
I am currently connecting to the Oracle "Rdb" 7.0 database (located on
VMS) - not Oracle Oracle.
The SQL Service software we're currently using is version 7.1. This
version works well with the OCI8 driver (when connecting to the
database from Windows NT). This version of SQL Service however does
NOT work for the THIN driver (unless we upgrade the SQL Service to
version 7.1.5.5 - which we're not prepared to do so because it is not
stable enough from our previous test/trials). SQLSRV Version 7.1.5.5
works for THIN driver but it will result in uncommitted
transactions/unresolved connection/stopping of listener issues and
there is a need to restart the service from time to time. Oracle has
since confirmed that this is a bug that they have yet to resolve...
So we have to stick to OCI8 (THICK) for the time being. I would really
appreciate it very much if you can tell me the various OCI libraries
that I need to load (in terms of WebLogic Server config file settings
etc..).
By the way I have already installed the Oracle 8 client software on
the NT server (where WebLogic Server is) and I have also set up the
relevant SID (using the Net8 Assistant) that points to the Oracle Rdb
database on the VMS. I have also tried using SQL*Plus to connect to
the database and I can connect properly to the database. But WebLogic
simply doesn't seem to load the software.
Help...
Regards,
Bobby Brown, writing from Australia.

Oracle JDBC Driver 10.1.0.4.0 and IndexOutOfBounds-Exception

Hello all,
we´ve experienced a weird problem using the Oracle JDBC driver version 10.1.0.4.0. While executing SELECT statement we get an ArrayIndexOutOfBounds exception from the JDBC driver. Here´s the stacktrace:
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at oracle.jdbc.driver.T4CDateAccessor.saveDataFromOldDefineBuffers(T4CDateAccessor.java:212)
at oracle.jdbc.driver.T4CPreparedStatement.saveDefineBuffersIfRequired(T4CPreparedStatement.java:405)
at oracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.java:859)
at oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:949)
at oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:532)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1037)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2905)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:2946)
at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:124)
We couldn´t find anything on the web on this error. We´re using Weblogic 8.1 SP4 with JDBC version. Does anyone have a hint or an idea what could be the problem here?
Thanks for any help in advance!
Cheers,
Joerg

I may have a related bug, I get a similiar exception when running JIRA...
java.lang.ArrayIndexOutOfBoundsException: -1
at oracle.jdbc.driver.DateTimeCommonAccessor.computeJulianDay(DateTimeCommonAccessor.java:341)
at oracle.jdbc.driver.DateTimeCommonAccessor.getMillis(DateTimeCommonAccessor.java:386)
at oracle.jdbc.driver.DateAccessor.getTimestamp(DateAccessor.java:142)
at oracle.jdbc.driver.OracleResultSetImpl.getTimestamp(OracleResultSetImpl.java:1018)...I tried the 10.1.0.2 and 10.1.0.4 drivers, both throw the same exception. I would try the 10.2 drivers, but they just hang! Gotta love Oracle QA!

Bug in Oracle UpdatableResultSet? (insert, updateString requires non-empty ResultSet?

As far as I can determine from the documentation and posts in other newsgroups
the following example should work to produce an updatable but "empty" ResultSet which can be used to insert rows.
But it doesn't work in a JDK 1.2.2 and JDK 1.3.0_01 application using Oracle 8i (8.1.7) thin JDBC
driver against an Oracle 8.1.5 database I get the following error
SQLException: java.sql.SQLException: Invalid argument(s) in call: setRowBufferAt
However, if I change it to so the target (ie insert) ResultSet is initialized to contain one or more
rows, it works just fine.
ResultSet rset2 = stmt2.executeQuery ( "select Context.* from Context where ContextCd = '0' " );
Is this a bug in Oracle's JDBC driver (more specifically, the UpdatableResultSet implimentation)?
Does an updatabable ResultSet have to return rows to be valid and useable for insert operations?
If it does, is there another way to create an updatable ResultSet that does not depend upon
"hard-coding" some known data value into the query?
try
// conn is a working, tested connection to an Oracle database via 8.1.7 thin JDBC driver.
// source statement
Statement stmt = conn.createStatement (
ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_READ_ONLY );
System.out.println("source rset");
rset = stmt.executeQuery ( "select Context.* from Context" );
// target Statement
Statement stmt2 = conn.createStatement (
ResultSet.TYPE_SCROLL_SENSITIVE, ResultSet.CONCUR_UPDATABLE );
ResultSet rset2 =
stmt2.executeQuery ( "select Context.* from Context where ContextCd = NULL" );
System.out.println(
"see if rset2 looks good even though empty (bcs primarykey = null)");
ResultSetMetaData rsmd2 = rset2.getMetaData();
int numColumns = rsmd2.getColumnCount();
for( int i = 0; i <= numColumns; i++ )
env.msg.println ( "(" + i + ") " + rsmd2.getColumnLabel(i) );
// test results showed the correct columns even though no row returned.
// quess we can use this trick to create an "empty" insert ResultSet.
System.out.println("interate through rset and insert using rset2");
if(rset.next())
System.out.println("move to insert row");
rset2.moveToInsertRow();
System.out.println("insert values");
rset2.updateString( "ContextCd", rset.getString("ContextCd") + "-test" );
rset2.updateString( "Descrip", "test" );
rset2.updateString( "Notes", "test" );
System.out.println("insert row into db (but not committed)");
rset2.insertRow();
catch( ... ) ...
Thanks
R.Parr
Temporal Arts

I have noticed the same problem, actually it doens't matter if there is no data in your resultset. If you have a result with data and suppose you were to analyze the data by moving through all of the rows, the cursor is now after the last row. If you call insertRow, the same exception is thrown. Kinda strange, I didn't get any response as to why this is happening and that was a few weeks ago. I hope someone responds, at this point I am just re-writing some of my code to not use updateable resultsets.
<BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Randall Parr ([email protected]):
As far as I can determine from the documentation and posts in other newsgroups
the following example should work to produce an updatable but "empty" ResultSet which can be used to insert rows.
But it doesn't work in a JDK 1.2.2 and JDK 1.3.0_01 application using Oracle 8i (8.1.7) thin JDBC
driver against an Oracle 8.1.5 database I get the following error<HR></BLOCKQUOTE>
null

Bug in Oracle's handling of transaction isolation levels?

Hello,
I think there is a bug in Oracle 9i database related to serializable transaction isolation level.
Here is the information about the server:
Operating System:     Microsoft Windows 2000 Server Version 5.0.2195 Service Pack 2 Build 2195
System type:          Single CPU x86 Family 6 Model 8 Stepping 10 GenuineIntel ~866 MHz
BIOS-Version:          Award Medallion BIOS v6.0
Locale:               German
Here is my information about the client computer:
Operaing system:     Microsoft Windows XP
System type:          IBM ThinkPad
Language for DB access: Java
Database information:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
The database has been set up using the default settings and nothing has been changed.
To reproduce the bug, follow these steps:
1. Create a user in 9i database called 'kaon' with password 'kaon'
2. Using SQL Worksheet create the following table:
CREATE TABLE OIModel (
modelID int NOT NULL,
logicalURI varchar (255) NOT NULL,
CONSTRAINT pk_OIModel PRIMARY KEY (modelID),
CONSTRAINT logicalURI_OIModel UNIQUE (logicalURI)
3. Run the following program:
package test;
import java.sql.*;
public class Test {
public static void main(String[] args) throws Exception {
java.util.Locale.setDefault(java.util.Locale.US);
Class.forName("oracle.jdbc.OracleDriver");
Connection connection=DriverManager.getConnection("jdbc:oracle:thin:@schlange:1521:ORCL","kaon","kaon");
DatabaseMetaData dmd=connection.getMetaData();
System.out.println("Product version:");
System.out.println(dmd.getDatabaseProductVersion());
System.out.println();
connection.setAutoCommit(false);
connection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
int batches=0;
int counter=2000;
for (int outer=0;outer<50;outer++) {
for (int i=0;i<200;i++) {
executeUpdate(connection,"INSERT INTO OIModel (modelID,logicalURI) VALUES ("+counter+",'start"+counter+"')");
executeUpdate(connection,"UPDATE OIModel SET logicalURI='next"+counter+"' WHERE modelID="+counter);
counter++;
connection.commit();
System.out.println("Batch "+batches+" done");
batches++;
protected static void executeUpdate(Connection conn,String sql) throws Exception {
Statement s=conn.createStatement();
try {
int result=s.executeUpdate(sql);
if (result!=1)
throw new Exception("Should update one row, but updated "+result+" rows, query is "+sql);
finally {
s.close();
The program prints the following output:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.lang.Exception: Should update one row, but updated 0 rows, query is UPDATE OIModel SET logicalURI='next2571' WHERE modelID=2571
     at test.Test.executeUpdate(Test.java:35)
     at test.Test.main(Test.java:22)
That is, after several iterations, the executeUpdate() method returns 0, rather than 1. This is clearly an error.
4. Leave the database as is. Replace the line
int counter=2000;
with line
int counter=4000;
and restart the program. The following output is generated:
Product version:
Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
Batch 0 done
Batch 1 done
java.sql.SQLException: ORA-08177: can't serialize access for this transaction
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
     at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289)
     at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573)
     at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1891)
     at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteFetch(TTC7Protocol.java:1093)
     at oracle.jdbc.driver.OracleStatement.executeNonQuery(OracleStatement.java:2047)
     at oracle.jdbc.driver.OracleStatement.doExecuteOther(OracleStatement.java:1940)
     at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:2709)
     at oracle.jdbc.driver.OracleStatement.executeUpdate(OracleStatement.java:796)
     at test.Test.executeUpdate(Test.java:33)
     at test.Test.main(Test.java:22)
This is clearly an error - only one transaction is being active at the time, so there is no need for serialization of transactions.
5. You can restart the program as many times you wish (by chaging the initial counter value first). The same error (can't serialize access for this transaction) will be generated.
6. The error doesn't occur if the transaction isolation level isn't changed.
7. The error doesn't occur if the UPDATE statement is commented out.
Sincerely yours
     Boris Motik

I have a similar problem
I'm using Oracle and serializable isolation level.
Transaction inserts 4000 objects and then updates about 1000 of these objects.
Transactions sees inserted objects but cant update them (row not found or can't serialize access for this transaction are thrown).
On 3 tries for this transaction 1 succeds and 2 fails with one of above errors.
No other transactions run concurently.
In read commited isolation error doesn't arise.
I'm using plain JDBC.
Similar or even much bigger serializable transaction works perfectly on the same database as plsql procedure.
I've tried oci and thin (Oracle) drivers and oranxo demo (i-net) driver.
And this problems arises on all of this drivers.
This problem confused me so much :(.
Maby one of Oracle users, developers nows cause of this strange behaviour.
Thanx for all answers.

Oracle jdbc driver spending 40 seconds to make connection to Oracle db 11g

we are using weblogic 10.3.3 and teh default Oracle11.1.0.7 Driver ojdbc6.jar to talk to Oracle db 11.2.0.1
After reviewing weblogic logs I see that it takes 50 secodns for each connection to db
HHere is a snippet (note I put in a 10 sec login dleay as i was experimenting, butt eh problem still occurs with or without login delay)
<Dec 21, 2010 1:28:19 AM GMT> <Info> <JDBC> <BEA-001516> <Connection Pool "acm_repository" connected to Database: "Oracle", Version: "Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options".>
Dec 21, 2010 1:28:19 AM GMT> <Info> <JDBC> <BEA-001517> <Connection Pool "acm_repository" using Driver: "Oracle JDBC driver", Version: "11.1.0.7.0-Production".>
<Dec 21, 2010 1:28:19 AM GMT> <Info> <JDBC> <BEA-001132> <Initialized statement cache of size "10" for connection in pool "acm_repository".>
<Dec 21, 2010 1:28:19 AM GMT> <Info> <JDBC> <BEA-001066> <Delaying 10 seconds before making a acm_repository pool connection.>
<Dec 21, 2010 1:29:09 AM GMT> <Info> <JDBC> <BEA-001068> <Connection for pool "acm_repository" created.>
There is someting wrong in this environment
I donwloaded the _g version fo teh exact same driver and had weblogic use it so I could generate verbose logs
Here is a snippet fo teh oracle drivers verbose log file . If you notice the key parts
it seems like its spending 40 second to make the connection, goes into a setConnectionDuringExceptionHandling method and creates the connection
can someone shed light on what causes itto go into an exception state
This happens for each and every connection but only in one specific environment
we have other environments which seem towork fine with the exact same product versions except for this environment
Thank you for any guidance on troubleshooting this further
-Y
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection parseConnectionProperty_Object
TRACE_16: Exit
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection readOCIConnectionPoolProperties
TRACE_16: Exit
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection readConnectionProperties
TRACE_16: Exit
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection initialize
TRACE_16: Enter: null, null, null
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection initialize
TRACE_16: Exit
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection needLine
TRACE_16: Enter:
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection needLineUnchecked
TRACE_16: Enter:
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection needLineUnchecked
TRACE_16: Exit
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.PhysicalConnection needLine
TRACE_16: Exit
Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.T4CConnection logon
**TRACE_16: Enter:**
**Dec 21, 2010 1:27:38 AM oracle.jdbc.driver.T4CConnection connect**
**TRACE_16: Enter: "10.135.3.80:1521:EPFDSQA"**
**Dec 21, 2010 1:28:18 AM oracle.jdbc.driver.T4CMAREngine setConnectionDuringExceptionHandling**
**TRACE_16: Enter:**
**Dec 21, 2010 1:28:18 AM oracle.jdbc.driver.T4CMAREngine setConnectionDuringExceptionHandling**
TRACE_16: ExitDec 21, 2010 1:28:18 AM oracle.jdbc.driver.DBConversion findDriverCharSet
TRACE_16: Enter: 178, 8100
Dec 21, 2010 1:28:18 AM oracle.jdbc.driver.DBConversion findDriverCharSet
TRACE_16: return: 178
Dec 21, 2010 1:28:18 AM oracle.jdbc.driver.DBConversion findDriverCharSet
TRACE_16: Exit
Dec 21, 2010 1:28:18 AM oracle.jdbc.driver.DBConversion <init>
TRACE_16: Enter: 178, 178, 2000
Dec 21, 2010 1:28:18 AM oracle.jdbc.driver.DBConversion init
TRACE_16: Enter: 178, 178, 2000

I would file an oracle jdbc bug to begin with, but I am guessing the driver is simply waiting
for the DBMS to respond, so yo may need a good DBA to see what the DBMS thinks is going
on at the time. I did hear of a case where the DBMS was doing some auditing, logging
some info during every login. This info was being written to an OS file which just happened
to be remote-mounted and would occasionally take 30 seconds, which caused connection
requests to timeout at the driver end.... WebLogic is just asking the driver for a connection
using your properties, so it's not involved directly with the problem....

Oracle/JDBC Memory Leak

I am using the Oracle 7 client with the JDBC driver for Java 2. I am also using the Sun jdk 1.3 SE. Every time I establish a connection to any Oracle database, there is a bit of memory that is lost and can not be reclaimed. A simple program that connects to the database via DriverManager.getConnection(), followed by Connection.close() inside a loop shows the memory gradually increasing. Is this a bug? If so, where is the patch?

the first jdbc drivers certified to work with java 2 (aka jdk 1.2) were called
"jdbc 8.1.6sdk". They have been replaced by jdbc816 and jdbc 817 plus their related patchsets.
the version 7 jdbc drivers went out of support on dec 31, 2000 along with the rdbms 7.3.x product suite.
patches are not generated for "out of support" products.
jdk 1.3 is not certified with any oracle jdbc drivers yet, however, some people have been able to use it with the 816 or 817 jdbc drivers with minimal problems.
be advised...
any problems you run into with oracle jdbc drivers while using jdk 1.3 must be reproduced with jdk 1.2.x in order for a bug to be filed.
i hope this helps ...
null

Bug in oracle jdbc faq

Similar Messages

Maybe you are looking for