Oracle JDBC driver's Isolation levels

Hi!
Is there a JDBC driver for oracle that supports transaction isolation levels other than TRANSACTION_READ_COMMITED and TRANSACTION_SERIALIZABLE?
Thanks!

Hi!
Is there a JDBC driver for oracle that supports transaction isolation levels other than TRANSACTION_READ_COMMITED and TRANSACTION_SERIALIZABLE?
Thanks!

Similar Messages

  • Oracle XA driver and isolation level

    We have an Entity EJB that has isolation level specified in its
    deployment descriptor and everything works fine if we use the non-XA
    Oracle 9i driver.
    However when we use the Oracle 9i Release 2 XA driver we get the
    following exception:
    java.sql.SQLException: Due to vendor limitations, setting transaction
    isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
    at
    weblogic.jdbc.jta.DataSource.setTxIsolationFromTxProp(DataSource.java:1126)
    at
    weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1109)
    at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145)
    at weblogic.jdbc.jta.Connection.getAutoCommit(Connection.java:247)
    at
    weblogic.jdbc.rmi.internal.ConnectionImpl.getAutoCommit(ConnectionImpl.java:173)
    at
    weblogic.jdbc.rmi.SerialConnection.getAutoCommit(SerialConnection.java:164)
    Note the 8.1.7 version that the container prints. The driver is
    definitely 9i and not 8.1.7 and it's the very first thing in the classpath.
    Is this a problem with the driver really or is it a WLS issue?
    Thanks,
    Dejan

    Hi,
    I removed the transaction isolation level setting from the deployment
    descriptor and it works now as expected.
    But in the meanwhile I also ran a test by using the driver directly
    without Weblogic and I was able to successfully set the transaction
    isolation level on the XA connections so I believe it's a Weblogic problem.
    Dejan
    Deyan D. Bektchiev wrote:
    Yes,
    We know about this but we just try to set it to the default one
    (READ_COMMITED) which is probably redundant for Oracle but might not
    be the default one for another DB vendor.
    Here is the part of the deployment descriptor:
    <transaction-isolation>
    <isolation-level>TRANSACTION_READ_COMMITTED</isolation-level>
    <method>
    <ejb-name>Event</ejb-name>
    <method-name>*</method-name>
    </method>
    </transaction-isolation>
    Dejan
    Slava Imeshev wrote:
    Deyan,
    I'm not 100% sure, but AFAIR oracle doesn't support all isolation
    levels.
    Which level do you set? Could you show us this part of the deployment
    descriptor?
    Slava
    "Deyan D. Bektchiev" <[email protected]> wrote in message
    news:[email protected]...
    Thanks for the reply Sree,
    Yes the 9i driver is the very first thing in the classpath as otherwise
    we wouldn't even be able to connect to the 9i database with the 8.1.7
    driver (we were getting lots of other exceptions when we were still
    using the 8.1.7 driver).
    I'll try removing the setting of the isolation level and I'll post the
    result to the newsgroup.
    Dejan
    Sree Bodapati wrote:
    hi Deyan,
    java.sql.SQLException: Due to vendor limitations, setting
    transaction
    isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
    should not have showed up with wrong version of oracle. If you can
    verifiy
    that the thin driver is the first thing in the classpath and you are
    indeed
    using the thin driver, This is a bug.
    But in this case it looks like you need to remove the
    TransactionIsolation
    level from the EJB descriptor to get this to work. can you try that? I
    will
    forward this to one of our EJB engineers and see if we can get some
    help
    for
    you.
    sree
    "Deyan D. Bektchiev" <[email protected]> wrote in message
    news:[email protected]...
    Sree,
    We already did but the only answer we got was that the Oracle 9i
    Release
    2 driver was not at all supported by Weblogic 7.0 SP1.
    But the certification page says that it is even certified...
    So which one is true: The Oracle 9i Release 2 driver is not
    supported or
    is supported?
    --dejan
    Sree Bodapati wrote:
    Please file a support case for this at [email protected]
    "Deyan D. Bektchiev" <[email protected]> wrote in message
    news:[email protected]...
    We have an Entity EJB that has isolation level specified in its
    deployment descriptor and everything works fine if we use the
    non-XA
    Oracle 9i driver.
    However when we use the Oracle 9i Release 2 XA driver we get the
    following exception:
    java.sql.SQLException: Due to vendor limitations, setting
    transaction
    isolation for "Oracle 8.1.7 XA" JDBC XA driver is not supported.
    at
    weblogic.jdbc.jta.DataSource.setTxIsolationFromTxProp(DataSource.java:1126
    at
    weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1109)
    at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:145)
    at
    weblogic.jdbc.jta.Connection.getAutoCommit(Connection.java:247)
    at
    weblogic.jdbc.rmi.internal.ConnectionImpl.getAutoCommit(ConnectionImpl.jav
    a
    >
    173)
    at
    weblogic.jdbc.rmi.SerialConnection.getAutoCommit(SerialConnection.java:164
    Note the 8.1.7 version that the container prints. The driver is
    definitely 9i and not 8.1.7 and it's the very first thing in the
    classpath.
    Is this a problem with the driver really or is it a WLS issue?
    Thanks,
    Dejan

  • Use of oracle.jdbc.driver now deprecated.

    Hi all,
    Just thought of sharing this note with us.,(if its new ..)
    http://otn.oracle.com/docs/products/oracle9i/doc_library/901_doc/java.901/a90211/overvw.htm#1008871
    Extract ...,
    Beginning in Oracle9i, the Oracle extensions to JDBC are captured in the package oracle.jdbc. This package contains classes and interfaces that specify the
    Oracle extensions in a manner similar to the way the classes and interfaces in java.sql specify the public JDBC API.
    Your code should use the package oracle.jdbc instead of the package oracle.jdbc.driver used in earlier versions of Oracle. Use of the package
    oracle.jdbc.driver is now deprecated, but will continue to be supported for backwards compatibility.
    All that is required to covert your code is to replace "oracle.jdbc.driver" with "oracle.jdbc" in the source and recompile. This cannot be done piece-wise.
    You must convert all classes and interfaces that are referenced by an application. Conversion is not required, but is highly recommended. Future releases of Oracle
    may have features that are incompatible with use of the package oracle.jdbc.driver.
    The purpose of this change is to enable the Oracle JDBC drivers to have multiple implementations. In all releases up to and including Oracle9i, all of the Oracle
    JDBC drivers have used the same top level implementation classes, the classes in the package oracle.jdbc.driver. By converting your code to use
    oracle.jdbc, you will be able to take advantage of future enhancements that use different implementation classes. There are no such enhancements in Oracle9i, but
    there are plans for such enhancements in the future.
    Regards
    Elango.

    The two main things that would have to change
    - driver : com.microsoft.sqlserver.jdbc.SQLServerDriver
    - url: jdbc:microsoft:sqlserver://localhost:1433
    It may be that this page will help you
    http://msdn.microsoft.com/data/learning/jdbc/
    You also need to make sure that the files Msbase.jar , Msutil.jar and Mssqlserver.jar are all available in the "classpath"
    For a web app, that means these files should be in the WEB-INF/lib directory.
    Good luck,
    evnafets

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

  • [Macromedia][Oracle JDBC Driver]Execution timeout expired

    From time to time, I get "[Macromedia][Oracle JDBC Driver]Execution timeout expired" errors in my log files on queries that should normally take < 10 ms. If this happens too often (the exact count seems to be different every time), ColdFusion stops responding (and logging!).
    Between CF and the Oracle DB server I have a firewall.
    The firewall seems to be ok, Oracle stops receiving db requests without further errors and CF stops without writing anything in the log files.
    What now? I'm using the latest CF9, fully patched and updated. We use a reboot script for the time beeing, but we'd like to know what is going on.

    Is there any way you can bypass the firewall on a networking level to rule it out?

  • Unable to load oracle.jdbc.driver.OracleDriver class

    i want to connect my java application with oracle database but i m getting an error -"class not found exception oracle.jdbc.driver.OracleDriver " which is written in Class.forName() to register the driver for DriverManager.
    plz help me..

    This is an old class, not included with the JDK anymore. It was made obsolete by
    DataSource which is a connection pool and not a single connection.

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

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

  • Oracle JDBC driver 10.1.0.2.0

    Hi All,
    I have installed Oracle 9iR2 on Windows 2000 Advance server, and i am looking for Oracle JDBC driver 10.1.0.2.0 to be installed and configured, it would be real help if some one could send me the download path and how to continue further with installing the JDBC driver
    Thanks,
    Kumar

    You can download the latest JDBC drivers from http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/index.html
    You just need to place the jar somewhere and add the location to your classpath.
    Kuassi

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

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

  • Issue encountered when Login as sysdba role using Thin Oracle JDBC Driver

    Hello all,
    we are now considering to use Thin oracle JDBC driver to create database in our project, but we met one issue when we tried to connect to oracle as sysdba role using Thin driver, and it throws java.sql.SQLException: Io Exception: SO Exception was generated, I have found some tips on oracle jdbc website and it says :
    How do I connect as SYSDBA or SYSOPER?
    The only way to do this is to use the Properties object when connecting, rather than specifying the username and password as strings. Put the username into the "user" property, and the password into the "password" property. Then, put the mode into the "internal_logon" property. Something like the following:
    Properties props = new Properties();
    props.put("user", "scott");
    props.put("password", "tiger");
    props.put("internal_logon", "sysoper");
    Connection conn = DriverManager.getConnection (url, props);
    When connecting as SYSDBA or SYSOPER using the Thin driver, the RDBMS must be configured to use a password file. See "Creating and Maintaining a Password File" in the "Oracle Database Administrator's Guide".
    So, i did execute orapwd command to create a password file and also set remote_login_passwordfile=execlusive in my initxxx.ora initial parameter file, however, when i tried to connect, it failed.
    private static void createEmsdbDatabase(){
    String url = "jdbc:oracle:thin:@localhost:1521:";
    StringBuffer sqlStatement = new StringBuffer();
    sqlStatement.append("create database xxx");
    sqlStatement.append("maxdatafiles 254 ");
    sqlStatement.append("maxinstances 8 ");
    sqlStatement.append("maxlogfiles 32 ");
    sqlStatement.append("character set UTF8 ");
    sqlStatement.append("national character set UTF8 ");
    sqlStatement.append("DATAFILE 'c:\\oracle\\xxx\\system01.dbf' SIZE 18M REUSE ");
    sqlStatement.append("logfile 'c:\\oracle\\xxx\\redo01.log' SIZE 2M REUSE, ");
    sqlStatement.append("'c:\\oracle\\xxx\\redo02.log' SIZE 2M REUSE, ");
    sqlStatement.append("'c:\\oracle\\xxx\\redo03.log' SIZE 2M REUSE ");
    try {
    DriverManager.registerDriver(new OracleDriver());
    Properties props = new Properties();
    props.put("user", "sys");
    props.put("password", "password");
    props.put("database","xxx");
    props.put("internal_logon", "sysdba");
    Connection conn = DriverManager.getConnection(url, props);
    Statement statement = conn.createStatement();
    statement.executeUpdate(sqlStatement.toString());
    statement.close();
    conn.close();
    } catch (SQLException e) {
    e.printStackTrace();
    But what made me puzzled a lot is if i use OCI driver, it did work great, why??? guys, anybody knows, please give me some tips, thanks in advance.
    regards,
    Kaixuan @ Shanghai

    clarify my question in detail:
    Step 1 : create password file using orapwd command
    Step 2 : create database instance using oradim command
    Step 3 : login using sys as sysdba to startup database, e.g startup nomount pfile='...\initxxx.ora'
    Step 4 : create database.
    java code showing below:
    private static void createEmsdbDatabase(){
    String url = "jdbc:oracle:thin:@localhost:1521:";
    StringBuffer sqlStatement = new StringBuffer();
    sqlStatement.append("create database xxx ");
    sqlStatement.append("maxdatafiles 254 ");
    sqlStatement.append("maxinstances 8 ");
    sqlStatement.append("maxlogfiles 32 ");
    sqlStatement.append("character set UTF8 ");
    sqlStatement.append("national character set UTF8 ");
    sqlStatement.append("DATAFILE 'c:\\oracle\\xxx\\system01.dbf' SIZE 18M REUSE ");
    sqlStatement.append("logfile 'c:\\oracle\\xxx\\redo01.log' SIZE 2M REUSE, ");
    sqlStatement.append("'c:\\oracle\\xxx\\redo02.log' SIZE 2M REUSE, ");
    sqlStatement.append("'c:\\oracle\\xxx\\redo03.log' SIZE 2M REUSE ");
    try {
    DriverManager.registerDriver(new OracleDriver());
    Properties props = new Properties();
    props.put("user", "sys");
    props.put("password", "password");
    props.put("database","xxx");
    props.put("internal_logon", "sysdba");
    Connection conn = DriverManager.getConnection(url, props);
    Statement statement = conn.createStatement();
    statement.executeUpdate(sqlStatement.toString());
    statement.close();
    conn.close();
    } catch (SQLException e) {
    e.printStackTrace();
    issue was met here, when i tried to login as sysdba using sys, and in my java code, i use Thin driver, it then thrus exception, but when OCI driver is used, it works great, i don't know why.
    that is, when i use "jdbc:oracle:oci8:@" as database URL and then properties.put("database","xxx"), it works great. but, when i use "jdbc:oracle:thin:@localhost:1521:" as database URL and then properties.put("database","xxx"), it failed. hopefully, i have clarified my question clearly. thanks.

  • S not found: oracle.jdbc.driver.OracleDriver

    In the log I get this error:
    15:17:14,503 INFO [STDOUT] **** Initilizing HibernatePlugIn **********
    15:17:14,972 INFO [STDOUT] Error while initializing hibernate: JDBC Driver cla
    s not found: oracle.jdbc.driver.OracleDriver
    15:17:14,972 INFO [STDOUT] *************************************

    fixed it by putting the jdbc jar files from oracle lib to the jboss lib

  • Exception "not implemented for class oracle.jdbc.driver.T4CNumberAccessor"

    Hello I'm having some troubles dealing with 'java.sql.Date' I'm working with express edition database and I have three classes(different packages)
    1.Mapper
    2.Objects Class
    3.ConsoleTest
    I need to get an arraylist of objects, some of which contain dates, but when try to do it I get this exception
    "java.sql.SQLException: Invalid column type: getDate not implemented for class oracle.jdbc.driver.T4CNumberAccessor"
    Do you have any idea how I can implement the getDate method for this T4CNumberAccessor
    Here are the methods that I'm using
    1.Mapper
    public ArrayList<Object> getAllTaskAuctions(Connection con)
              ArrayList<Object> l1 = new ArrayList<Object>();
              String SQLString1 = "select * from taskauction natural join tasks";
    PreparedStatement statement=null;
    try
    //=== get taskauctions natural join tasks
    statement = con.prepareStatement(SQLString1);
    ResultSet rs = statement.executeQuery();
    while(rs.next())
    l1.add(new TaskAuction(rs.getInt(1), rs.getInt(2), rs.getInt(3),
    rs.getDate(4), rs.getDate(5), rs.getInt(6)));
    l1.add(new Task(rs.getInt(1), rs.getInt(2), rs.getString(3),
    rs.getString(4), rs.getString(5), rs.getString(6), rs.getInt(7)));
    catch (Exception exc)
    System.out.println("Fail in TaskAuctionMapper - getAllTaskAuctions");
    System.out.println(exc);
    return l1;
    2.ConsoleTest class
    Connection con;
         public Connection getConnection(){
              try{ 
         Class.forName("oracle.jdbc.driver.OracleDriver");
         con = DriverManager.getConnection(
         "jdbc:oracle:thin:@localhost:1521:XE", "Project", "123" );
         //username/password@[/]host[:port][service_name]
         catch (Exception e)
         {   System.out.println("fail in getConnection()");
         System.out.println(e); }
              return con;
         public static void main(String[] args) {
              ConsoleTest ct = new ConsoleTest();
              TaskAuctionMapper tam1 = new TaskAuctionMapper();
    ArrayList<Object> alt1 = tam1.getAllTaskAuctions(ct.getConnection());
    Iterator<Object> itr1 = alt1.iterator();
    while (itr1.hasNext())
    TaskAuction taskauct = (TaskAuction) itr1.next();
    //Problem, exception traced to TaskAuctionMapper
    System.out.println(
              "Task ID: " + taskauct.getTaskid()+ ", "+
              "StartDate: "+ taskauct.getStartdate()+", "+
              "User ID: " + taskauct.getUserid());
         }

    Found the answer, I shouldn't use integers as parameters of column index in the result set, but instead use String to mark the fields :)

Maybe you are looking for