Commons Dbcp
  1. Commons Dbcp
  2. DBCP-350

Problem with DBCP 1.3 /jdk 6 and oracle spatial

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 1.3, 1.4
    • Fix Version/s: 1.3.1, 1.4.1
    • Labels:
      None
    • Environment:

      CentOS 5.5 x86_64, Oracle JDK 1.6u22 32bit, Tomcat 5.5.31, ojdbc6.jar

      Description

      We have a GIS-application running on Tomcat 5.5. As webserver we are using
      Apache httpd 2.2 connected to tomcat via ajp (mod_proxy_ajp).

      The application worked fine with Tomcat 5.5.28 until we tried to upgrade to Tomcat 5.5.31.

      After the upgrade we get - in certain situations a:
      java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get
      at the OracleSpatial Connection object from the PreparedStatement.

      After looking through the Tomcat 5.5 changelogs we stumbled across a change
      made in 5.5.30: Upgrade to DBCP 1.3.

      I can affirm now that the problem is gone when downgrading to DBCP 1.2.2.
      The same problem occurs when using DBCP 1.4.

      It seems something has changed from 1.2.2 to 1.3 that has partially broken Oracle-Locator operations in dbcp 1.3
      I've seen some bug-reports for dbcp 1.3.1 which point in the same direction (oracle-db-error lead to java error) - perhaps these are the same problems...

        Activity

        Hide
        Sebb added a comment - - edited

        See also https://issues.apache.org/bugzilla/show_bug.cgi?id=50326 where this was originally reported.

        Can you provide a sample of the code that is failing?
        That would make it easier to track down.

        Or at least a stack trace.

        Show
        Sebb added a comment - - edited See also https://issues.apache.org/bugzilla/show_bug.cgi?id=50326 where this was originally reported. Can you provide a sample of the code that is failing? That would make it easier to track down. Or at least a stack trace.
        Hide
        Nils Hildebrand added a comment -

        Hi,

        find below an example of the full error message - imho it does not say
        much, since the first exception mentioned seems to be the problem.

        I did a network trace of the DB-connection and found some ORA-not-found
        messages.
        How can I trace this further down?

        Since I am not a java-developer I can't give you a short code snippet
        that will trigger the same error.

        FATAL 2010-11-24 11:08:29,245 - TP-Processor8
        de.ivu.web.common.web.FrontController: FrontController.doGet():
        Exception im FrontController.doGet!!!
        org.hibernate.HibernateException:
        org.hibernatespatial.helper.FinderException: Couldn't get at the
        OracleSpatial Connection object from the PreparedStatement.
        at
        org.hibernatespatial.oracle.SDOGeometryType.nullSafeSet(SDOGeometryType.
        java:109)
        at
        org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUserType.java:
        184)
        at
        org.hibernate.type.CustomType.nullSafeSet(CustomType.java:156)
        at
        org.hibernate.loader.Loader.bindPositionalParameters(Loader.java:1707)
        at
        org.hibernate.loader.Loader.bindParameterValues(Loader.java:1678)
        at
        org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1563)
        at org.hibernate.loader.Loader.doQuery(Loader.java:673)
        at
        org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loade
        r.java:236)
        at org.hibernate.loader.Loader.doList(Loader.java:2220)
        at
        org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104)
        at org.hibernate.loader.Loader.list(Loader.java:2099)
        at
        org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94
        )
        at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569)
        at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)
        at
        de.ivu.bamf.webgis.db.bohelper.SportvereinHelper.createBOs(SportvereinHe
        lper.java:61)
        at
        de.ivu.bamf.webgis.db.bohelper.SportvereinHelper.createBOs(SportvereinHe
        lper.java:83)
        at
        de.ivu.bamf.webgis.db.DefaultDBController.getFeatures(DefaultDBControlle
        r.java:198)
        at
        de.ivu.bamf.webgis.worker.search.CalculateExtendedSearchResultWorker.dot
        heWork(CalculateExtendedSearchResultWorker.java:576)
        at de.ivu.web.common.web.WebCommand.execute(WebCommand.java:93)
        at
        de.ivu.web.common.web.Dispatcher.dispatch(Dispatcher.java:106)
        at
        de.ivu.web.common.web.FrontController.doGet(FrontController.java:94)
        at
        de.ivu.web.common.web.FrontController.doPost(FrontController.java:177)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:647)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
        at
        org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
        tionFilterChain.java:269)
        at
        org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
        erChain.java:188)
        at
        org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv
        e.java:213)
        at
        org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv
        e.java:172)
        at
        org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
        :127)
        at
        org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
        :117)
        at
        org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
        java:108)
        at
        org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
        74)
        at
        org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
        at
        org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
        at
        org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
        at
        org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
        704)
        at
        org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.
        java:897)
        at
        org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
        .java:689)
        at java.lang.Thread.run(Thread.java:662)
        Caused by: org.hibernatespatial.helper.FinderException: Couldn't get at
        the OracleSpatial Connection object from the PreparedStatement.
        at
        org.hibernatespatial.oracle.DefaultConnectionFinder.find(DefaultConnecti
        onFinder.java:73)
        at
        org.hibernatespatial.oracle.DefaultConnectionFinder.find(DefaultConnecti
        onFinder.java:51)
        at
        org.hibernatespatial.oracle.SDOGeometryType.nullSafeSet(SDOGeometryType.
        java:105)
        ... 38 more

        Kind regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi, find below an example of the full error message - imho it does not say much, since the first exception mentioned seems to be the problem. I did a network trace of the DB-connection and found some ORA-not-found messages. How can I trace this further down? Since I am not a java-developer I can't give you a short code snippet that will trigger the same error. FATAL 2010-11-24 11:08:29,245 - TP-Processor8 de.ivu.web.common.web.FrontController: FrontController.doGet(): Exception im FrontController.doGet!!! org.hibernate.HibernateException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. at org.hibernatespatial.oracle.SDOGeometryType.nullSafeSet(SDOGeometryType. java:109) at org.hibernatespatial.GeometryUserType.nullSafeSet(GeometryUserType.java: 184) at org.hibernate.type.CustomType.nullSafeSet(CustomType.java:156) at org.hibernate.loader.Loader.bindPositionalParameters(Loader.java:1707) at org.hibernate.loader.Loader.bindParameterValues(Loader.java:1678) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1563) at org.hibernate.loader.Loader.doQuery(Loader.java:673) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loade r.java:236) at org.hibernate.loader.Loader.doList(Loader.java:2220) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2104) at org.hibernate.loader.Loader.list(Loader.java:2099) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:94 ) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283) at de.ivu.bamf.webgis.db.bohelper.SportvereinHelper.createBOs(SportvereinHe lper.java:61) at de.ivu.bamf.webgis.db.bohelper.SportvereinHelper.createBOs(SportvereinHe lper.java:83) at de.ivu.bamf.webgis.db.DefaultDBController.getFeatures(DefaultDBControlle r.java:198) at de.ivu.bamf.webgis.worker.search.CalculateExtendedSearchResultWorker.dot heWork(CalculateExtendedSearchResultWorker.java:576) at de.ivu.web.common.web.WebCommand.execute(WebCommand.java:93) at de.ivu.web.common.web.Dispatcher.dispatch(Dispatcher.java:106) at de.ivu.web.common.web.FrontController.doGet(FrontController.java:94) at de.ivu.web.common.web.FrontController.doPost(FrontController.java:177) at javax.servlet.http.HttpServlet.service(HttpServlet.java:647) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValv e.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValv e.java:172) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 74) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java: 704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket. java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:689) at java.lang.Thread.run(Thread.java:662) Caused by: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. at org.hibernatespatial.oracle.DefaultConnectionFinder.find(DefaultConnecti onFinder.java:73) at org.hibernatespatial.oracle.DefaultConnectionFinder.find(DefaultConnecti onFinder.java:51) at org.hibernatespatial.oracle.SDOGeometryType.nullSafeSet(SDOGeometryType. java:105) ... 38 more Kind regards Nils
        Hide
        Sebb added a comment -

        The stack trace is not an IOException, so does not appear to be the same as the original report.

        Also, DBCP does not appear in the stack trace, so this is probably a different error.

        Can you provide an example of the IOException please?

        Show
        Sebb added a comment - The stack trace is not an IOException, so does not appear to be the same as the original report. Also, DBCP does not appear in the stack trace, so this is probably a different error. Can you provide an example of the IOException please?
        Hide
        Phil Steitz added a comment -

        Can you please post your DBCP config?

        Show
        Phil Steitz added a comment - Can you please post your DBCP config?
        Hide
        Nils Hildebrand added a comment -

        Hi,

        ok - that was the trace of another error, that, too - was gone when
        downgrading to 1.2.2 - I thought it was the same thing.

        But again - dbcp is not visible in that stacktrace. At the moment I am
        following a different path:
        This could be a oracle-rights-problem. We tried to reproduce the error
        with dbcp 1.3 (tomcat 5.5.31) while using our developement environment
        (Eclipse) - there the error was absent. After further invstigation we
        found that the db-access was done with the scheme-owner - so the rights
        of the access-user were unlimited in the development environment.

        I am now comparing sql-traces between dbcp 1.4 with limited access-user
        (where the problem exists) and dbcp 1.2.2 with the same limited
        access-user (where the problem does not exist).

        Was there a change regarding access-error handling where dbcp 1.2.2
        ignored the error and 1.4/1.3?
        But why does dbcp not turn up in the stacktrace?

        Here it comes:

        ERROR 2010-12-07 12:31:12,640 - TP-Processor2
        org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/BAMF].[f
        rontControl]: ApplicationDispatcher.invoke(): Servlet.service() for
        servlet frontControl threw exception
        java.io.IOException: org.hibernatespatial.helper.FinderException:
        Couldn't get at the OracleSpatial Connection object from the
        PreparedStatement.
        at
        de.ivu.web.common.web.FrontController.doGet(FrontController.java:101)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:627)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
        at
        org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica
        tionFilterChain.java:269)
        at
        org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt
        erChain.java:188)
        at
        org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc
        her.java:659)
        at
        org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicatio
        nDispatcher.java:459)
        at
        org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp
        atcher.java:395)
        at
        org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispat
        cher.java:311)
        at
        org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java
        :364)
        at
        org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java
        :285)
        at
        org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.j
        ava:229)
        at
        org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java
        :135)
        at
        org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java
        :117)
        at
        org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.
        java:108)
        at
        org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1
        74)
        at
        org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
        at
        org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291)
        at
        org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775)
        at
        org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
        704)
        at
        org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.
        java:897)
        at
        org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool
        .java:689)
        at java.lang.Thread.run(Thread.java:662)

        Show
        Nils Hildebrand added a comment - Hi, ok - that was the trace of another error, that, too - was gone when downgrading to 1.2.2 - I thought it was the same thing. But again - dbcp is not visible in that stacktrace. At the moment I am following a different path: This could be a oracle-rights-problem. We tried to reproduce the error with dbcp 1.3 (tomcat 5.5.31) while using our developement environment (Eclipse) - there the error was absent. After further invstigation we found that the db-access was done with the scheme-owner - so the rights of the access-user were unlimited in the development environment. I am now comparing sql-traces between dbcp 1.4 with limited access-user (where the problem exists) and dbcp 1.2.2 with the same limited access-user (where the problem does not exist). Was there a change regarding access-error handling where dbcp 1.2.2 ignored the error and 1.4/1.3? But why does dbcp not turn up in the stacktrace? Here it comes: ERROR 2010-12-07 12:31:12,640 - TP-Processor2 org.apache.catalina.core.ContainerBase. [Catalina] . [localhost] . [/BAMF] .[f rontControl]: ApplicationDispatcher.invoke(): Servlet.service() for servlet frontControl threw exception java.io.IOException: org.hibernatespatial.helper.FinderException: Couldn't get at the OracleSpatial Connection object from the PreparedStatement. at de.ivu.web.common.web.FrontController.doGet(FrontController.java:101) at javax.servlet.http.HttpServlet.service(HttpServlet.java:627) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applica tionFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilt erChain.java:188) at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatc her.java:659) at org.apache.catalina.core.ApplicationDispatcher.processRequest(Applicatio nDispatcher.java:459) at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDisp atcher.java:395) at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispat cher.java:311) at org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java :364) at org.apache.catalina.core.StandardHostValve.status(StandardHostValve.java :285) at org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.j ava:229) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java :135) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java :117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve. java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:1 74) at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:291) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:775) at org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java: 704) at org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket. java:897) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool .java:689) at java.lang.Thread.run(Thread.java:662)
        Hide
        Nils Hildebrand added a comment -

        Hi Phil,

        sure. This is from the tomcat-server.xml. I replaced username, password,
        url-db, port and sid with dummy-values.
        DB-Connect is done via two resources using the dbcp-factory:

        <Resource name="WEBGISREAD"
        auth="Container"
        type="javax.sql.DataSource"
        factory="org.apache.commons.dbcp.BasicDataSourceFactory"
        username="DB_READER_ROLE" password="SECRET"
        driverClassName="oracle.jdbc.OracleDriver"
        url="jdbc:oracle:thin:@db4711:4711:db4711"
        maxWait="-1"
        removeAbandoned="true"
        maxActive="30"
        maxIdle="10"
        removeAbandonedTimeout="60"
        logAbandoned="true"/>

        <Resource name="WEBGISWRITE"
        auth="Container"
        type="javax.sql.DataSource"
        factory="org.apache.commons.dbcp.BasicDataSourceFactory"
        username="DB_WRITER_ROLE" password="TOPSECRET"
        driverClassName="oracle.jdbc.OracleDriver"
        url="jdbc:oracle:thin:@db4711:4711:db4711"
        maxWait="-1"
        removeAbandoned="true"
        maxActive="30"
        maxIdle="10"
        removeAbandonedTimeout="60"
        logAbandoned="true"
        defaultAutoCommit="false" />

        Kind regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi Phil, sure. This is from the tomcat-server.xml. I replaced username, password, url-db, port and sid with dummy-values. DB-Connect is done via two resources using the dbcp-factory: <Resource name="WEBGISREAD" auth="Container" type="javax.sql.DataSource" factory="org.apache.commons.dbcp.BasicDataSourceFactory" username="DB_READER_ROLE" password="SECRET" driverClassName="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:@db4711:4711:db4711" maxWait="-1" removeAbandoned="true" maxActive="30" maxIdle="10" removeAbandonedTimeout="60" logAbandoned="true"/> <Resource name="WEBGISWRITE" auth="Container" type="javax.sql.DataSource" factory="org.apache.commons.dbcp.BasicDataSourceFactory" username="DB_WRITER_ROLE" password="TOPSECRET" driverClassName="oracle.jdbc.OracleDriver" url="jdbc:oracle:thin:@db4711:4711:db4711" maxWait="-1" removeAbandoned="true" maxActive="30" maxIdle="10" removeAbandonedTimeout="60" logAbandoned="true" defaultAutoCommit="false" /> Kind regards Nils
        Hide
        Mark Thomas added a comment -

        I believe there is a configuration problem.

        The conection pools are using the deprecated "oracle.jdbc.OracleDriver" that return connections of type oracle.jdbc.OracleConnection. However, the HibernateSpatial (trunk at least) is looking for the newer oracle.jdbc.driver.OracleConnection which are returned when using the newer oracle.jdbc.driver.OracleDriver. I suspect switching your connection pools to use oracle.jdbc.driver.OracleDriver will fix this issue.

        Show
        Mark Thomas added a comment - I believe there is a configuration problem. The conection pools are using the deprecated "oracle.jdbc.OracleDriver" that return connections of type oracle.jdbc.OracleConnection. However, the HibernateSpatial (trunk at least) is looking for the newer oracle.jdbc.driver.OracleConnection which are returned when using the newer oracle.jdbc.driver.OracleDriver. I suspect switching your connection pools to use oracle.jdbc.driver.OracleDriver will fix this issue.
        Hide
        Nils Hildebrand added a comment -

        Hi Mark,

        http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.h
        tml#Oracle_8i,9i&_10g

        This states it the other way round - that's why I changed it from
        oracle.jdbc.driver.OracleDriver to oracle.jdbc.OracleDriver - but
        nevertheless I got the same error picture before that change.

        No - this seems to be a DB-access-right related problem The big question
        is now why the problem did not exist prior to dbcp 1.3.

        Kind regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi Mark, http://tomcat.apache.org/tomcat-5.5-doc/jndi-datasource-examples-howto.h tml#Oracle_8i, 9i &_10g This states it the other way round - that's why I changed it from oracle.jdbc.driver.OracleDriver to oracle.jdbc.OracleDriver - but nevertheless I got the same error picture before that change. No - this seems to be a DB-access-right related problem The big question is now why the problem did not exist prior to dbcp 1.3. Kind regards Nils
        Hide
        Mark Thomas added a comment -

        Sorry for the mix up, you're right about the deprecation. HibernateSpatial is still looking for the older class. I assume that that class is the actual implementation which is why it works although trying to find the Javadocs to confirm this is like pulling teeth (which is partly what caused my previous mix-up).

        Regarding the access rights issue, I've looked through http://commons.apache.org/dbcp/changes-report.html and nothing jumps out at me as a possible trigger. Is there anything in the oracle logs that shed any light?

        Show
        Mark Thomas added a comment - Sorry for the mix up, you're right about the deprecation. HibernateSpatial is still looking for the older class. I assume that that class is the actual implementation which is why it works although trying to find the Javadocs to confirm this is like pulling teeth (which is partly what caused my previous mix-up). Regarding the access rights issue, I've looked through http://commons.apache.org/dbcp/changes-report.html and nothing jumps out at me as a possible trigger. Is there anything in the oracle logs that shed any light?
        Hide
        Nils Hildebrand added a comment -

        Hi,

        yes - I think I got a hit in the oracle-logs. I am doing the same thing
        via GUI with DBCP 1.4 and DBCP 1.2.2.
        In the middle of the traces some SQL-statements are missing.

        Using DBCP 1.2.2 I get:

        – snip –
        declare
        cost sys.ODCICost := sys.ODCICost(NULL, NULL, NULL, NULL);
        obj0 "MDSYS"."SDO_GEOMETRY" := "MDSYS"."SDO_GEOMETRY"(NULL, NULL,
        NULL, NULL, NULL);
        obj1 "MDSYS"."SDO_GEOMETRY" := "MDSYS"."SDO_GEOMETRY"(NULL, NULL,
        NULL, NULL, NULL);

        begin
        :1 := "MDSYS"."SDO_STATISTICS".ODCIStatsFunctionCost(
        sys.ODCIFuncInfo('MDSYS',
        'SDO_3GL',
        'FILTER',
        2),
        cost,
        sys.ODCIARGDESCLIST(sys.ODCIARGDESC(2,
        'LIKT_BKE_KURSE_O_GEOM', 'WEBGISDB', '"GEOLOC"', NULL, NULL, NULL),
        sys.ODCIARGDESC(1, NULL, NULL, NULL, NULL, NULL, NULL),
        sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL))
        , obj0, obj1, :5,
        sys.ODCIENV(:6,:7,:8,:9));
        if cost.CPUCost IS NULL then
        :2 := -1.0;
        else
        :2 := cost.CPUCost;
        end if;
        if cost.IOCost IS NULL then
        :3 := -1.0;
        else
        :3 := cost.IOCost;
        end if;
        if cost.NetworkCost IS NULL then
        :4 := -1.0;
        else
        :4 := cost.NetworkCost;
        end if;
        exception
        when others then
        raise;
        end;
        – snap –

        That is the first statement that is missing completely from the DBCP
        1.4-trace!
        Next come two more "declare"-SQL-statements (also - both missing in
        1.4), then the trace joins again at a select-statement.

        I will now make a cross-check using DBCP 1.4 and full DB-access-rights
        outside Eclipse in my normal Linux-server environment.

        Kind regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi, yes - I think I got a hit in the oracle-logs. I am doing the same thing via GUI with DBCP 1.4 and DBCP 1.2.2. In the middle of the traces some SQL-statements are missing. Using DBCP 1.2.2 I get: – snip – declare cost sys.ODCICost := sys.ODCICost(NULL, NULL, NULL, NULL); obj0 "MDSYS"."SDO_GEOMETRY" := "MDSYS"."SDO_GEOMETRY"(NULL, NULL, NULL, NULL, NULL); obj1 "MDSYS"."SDO_GEOMETRY" := "MDSYS"."SDO_GEOMETRY"(NULL, NULL, NULL, NULL, NULL); begin :1 := "MDSYS"."SDO_STATISTICS".ODCIStatsFunctionCost( sys.ODCIFuncInfo('MDSYS', 'SDO_3GL', 'FILTER', 2), cost, sys.ODCIARGDESCLIST(sys.ODCIARGDESC(2, 'LIKT_BKE_KURSE_O_GEOM', 'WEBGISDB', '"GEOLOC"', NULL, NULL, NULL), sys.ODCIARGDESC(1, NULL, NULL, NULL, NULL, NULL, NULL), sys.ODCIARGDESC(3, NULL, NULL, NULL, NULL, NULL, NULL)) , obj0, obj1, :5, sys.ODCIENV(:6,:7,:8,:9)); if cost.CPUCost IS NULL then :2 := -1.0; else :2 := cost.CPUCost; end if; if cost.IOCost IS NULL then :3 := -1.0; else :3 := cost.IOCost; end if; if cost.NetworkCost IS NULL then :4 := -1.0; else :4 := cost.NetworkCost; end if; exception when others then raise; end; – snap – That is the first statement that is missing completely from the DBCP 1.4-trace! Next come two more "declare"-SQL-statements (also - both missing in 1.4), then the trace joins again at a select-statement. I will now make a cross-check using DBCP 1.4 and full DB-access-rights outside Eclipse in my normal Linux-server environment. Kind regards Nils
        Hide
        Nils Hildebrand added a comment -

        Hi Phil,

        from my side no good news for this one - even with the
        oracle-access-users changed to the sceme-owner the error remains.

        It does not occur in Eclipse/Windows Tomcat 5.5.31 though.
        Is there a difference between win dbcp and linux dbcp which could
        explain that?

        Is there any possibility to track sql-operations further down with some
        dbcp-logging-options?

        Kind regards

        Nils

        ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

        Show
        Nils Hildebrand added a comment - Hi Phil, from my side no good news for this one - even with the oracle-access-users changed to the sceme-owner the error remains. It does not occur in Eclipse/Windows Tomcat 5.5.31 though. Is there a difference between win dbcp and linux dbcp which could explain that? Is there any possibility to track sql-operations further down with some dbcp-logging-options? Kind regards Nils ian.jira.plugin.system.issuetabpanels:all-tabpanel ]
        Hide
        Phil Steitz added a comment -

        DBCP is 100% Java - there should be no difference on Linux vs Windows; though of course the drivers that DBCP instantiates could be behaving differently.

        There is currently no logging in DBCP.

        What exactly is your code doing during the traces above?

        Show
        Phil Steitz added a comment - DBCP is 100% Java - there should be no difference on Linux vs Windows; though of course the drivers that DBCP instantiates could be behaving differently. There is currently no logging in DBCP. What exactly is your code doing during the traces above?
        Hide
        Nils Hildebrand added a comment -

        Hi,

        good question.

        Since I can't trace within Windows/Eclipse (no error there!) - how do I
        trace in the "live" linux tomcat environment?

        Basically I posted the SQL-Statements that are being done before the
        error occurs.
        That trace was done on the db-server.

        Kind regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi, good question. Since I can't trace within Windows/Eclipse (no error there!) - how do I trace in the "live" linux tomcat environment? Basically I posted the SQL-Statements that are being done before the error occurs. That trace was done on the db-server. Kind regards Nils
        Hide
        Phil Steitz added a comment -

        Can you relate the GUI actions that you are taking in the linux tomcat environment to statements executed by the code?

        Show
        Phil Steitz added a comment - Can you relate the GUI actions that you are taking in the linux tomcat environment to statements executed by the code?
        Hide
        Nils Hildebrand added a comment -

        Hi,

        I asked the question on a GIS-Forum at Stack-Exchange.

        I’ve got an answer that sounds very like the root-cause of the problem – located within hibernatespatial.

        See below…

        Does it ring a bell with you?

        Kind regards

        Nils

        Von: Stack Exchange do-not-reply@stackexchange.com
        Gesendet: Donnerstag, 11. August 2011 06:00

        Any known problems after Tomcat-upgrade using oracle locator? <http://gis.stackexchange.com/questions/13105/any-known-problems-after-tomcat-upgrade-using-oracle-locator>

        Show
        Nils Hildebrand added a comment - Hi, I asked the question on a GIS-Forum at Stack-Exchange. I’ve got an answer that sounds very like the root-cause of the problem – located within hibernatespatial. See below… Does it ring a bell with you? Kind regards Nils Von: Stack Exchange do-not-reply@stackexchange.com Gesendet: Donnerstag, 11. August 2011 06:00 Any known problems after Tomcat-upgrade using oracle locator? < http://gis.stackexchange.com/questions/13105/any-known-problems-after-tomcat-upgrade-using-oracle-locator >
        Hide
        Mark Thomas added a comment -

        The analysis shows that this is caused by hibernate needing to access the raw Oracle connection but DBCP is returning wrapped objects. That makes this a hibernate issue unless DBCP does not provide a mechanism for hibernate to access the raw connection (which I believe it does).

        I don't see anything for DBCP to fix here.

        Show
        Mark Thomas added a comment - The analysis shows that this is caused by hibernate needing to access the raw Oracle connection but DBCP is returning wrapped objects. That makes this a hibernate issue unless DBCP does not provide a mechanism for hibernate to access the raw connection (which I believe it does). I don't see anything for DBCP to fix here.
        Hide
        Nils Hildebrand added a comment -

        Hi Mark,

        so dbcp does not use hibernate?
        I am confused.

        I am not a developer - I just want to see this bug fixed in Tomcat so I can use a standard-tomcat again.
        I played the game to escalate this to dbcp.

        But I will not play the game to escalate this further to hibernate - there seems to be a ready to use bug-fix there (at hibernate).
        So implement it into dbcp 1.3.n or 1.4.n and I am willing to test it again.

        If that fixes the problem I will report back to Tomcat so they can upgrade to dbcp 1.3.n or dbcp 1.4.n as well.

        Is this open source or is this "I am the big bug closer, but am not interested in fixing problems"?

        I've got my working workaround in place (commons.dbcp 1.2.2) - but I don't think this is helpful neither for tomcat nor dbcp nor the community.

        Regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi Mark, so dbcp does not use hibernate? I am confused. I am not a developer - I just want to see this bug fixed in Tomcat so I can use a standard-tomcat again. I played the game to escalate this to dbcp. But I will not play the game to escalate this further to hibernate - there seems to be a ready to use bug-fix there (at hibernate). So implement it into dbcp 1.3.n or 1.4.n and I am willing to test it again. If that fixes the problem I will report back to Tomcat so they can upgrade to dbcp 1.3.n or dbcp 1.4.n as well. Is this open source or is this "I am the big bug closer, but am not interested in fixing problems"? I've got my working workaround in place (commons.dbcp 1.2.2) - but I don't think this is helpful neither for tomcat nor dbcp nor the community. Regards Nils
        Hide
        Mark Thomas added a comment -

        No, DBCP does not use hibernate. Your application is using hibernate and hibernate is using DBCP, a version of which is packaged inside Apache Tomcat.

        There is no bug in Tomcat or DBCP to fix. The bug - if there is one - in hibernate or possibly your application.

        The hibernate folks are taking the understandable view that this is not a bug in hibernate. In this case hibernate needs access to the raw connection and it isn't really practical for hibernate to handle all possible scenarios for what it might need to do to access the raw connection. Hibernate provides a default mechanism to obtain the raw connection and provides an extension point for users to provide their own mechanism where the default mechanism doesn't work.

        The application that is using hibernate needs to provide an appropriate implementation of hibernate's ConnectionFinder.

        Yes this is open source but just because you are using DBCP as embedded in Tomcat that does not make all database problems you come across DBCP or Tomcat bugs. While the problem you are seeing was triggered by a change to DBCP that still does not make this a DBCP bug. Hibernate was relying on the raw connection being available which is not a valid assumption in an environment using connection pooling.

        The community has provided you with all the information you need to fix the problem you are experiencing with your application.

        Show
        Mark Thomas added a comment - No, DBCP does not use hibernate. Your application is using hibernate and hibernate is using DBCP, a version of which is packaged inside Apache Tomcat. There is no bug in Tomcat or DBCP to fix. The bug - if there is one - in hibernate or possibly your application. The hibernate folks are taking the understandable view that this is not a bug in hibernate. In this case hibernate needs access to the raw connection and it isn't really practical for hibernate to handle all possible scenarios for what it might need to do to access the raw connection. Hibernate provides a default mechanism to obtain the raw connection and provides an extension point for users to provide their own mechanism where the default mechanism doesn't work. The application that is using hibernate needs to provide an appropriate implementation of hibernate's ConnectionFinder. Yes this is open source but just because you are using DBCP as embedded in Tomcat that does not make all database problems you come across DBCP or Tomcat bugs. While the problem you are seeing was triggered by a change to DBCP that still does not make this a DBCP bug. Hibernate was relying on the raw connection being available which is not a valid assumption in an environment using connection pooling. The community has provided you with all the information you need to fix the problem you are experiencing with your application.
        Hide
        Nils Hildebrand added a comment -

        Hi Mark,

        thanks for this explanation and my apologies for not knowing the technical implications.

        The question that still arises is: If it is an application and/or hibernate problem (which is quite sure now)

        • why does the problem not hit the application when using the "old" dbcp 1.2.2?

        Was DBCP more error tolerant with regards to hybernate in that version?

        Kind regards

        Nils

        Show
        Nils Hildebrand added a comment - Hi Mark, thanks for this explanation and my apologies for not knowing the technical implications. The question that still arises is: If it is an application and/or hibernate problem (which is quite sure now) why does the problem not hit the application when using the "old" dbcp 1.2.2? Was DBCP more error tolerant with regards to hybernate in that version? Kind regards Nils

          People

          • Assignee:
            Unassigned
            Reporter:
            Nils Hildebrand
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development