Re: Is perl better? :(((

From: Joe Weinstein (joeNOSPAM_at_bea.com)
Date: 02/05/05

  • Next message: Tor Iver Wilhelmsen: "Re: Why default parameter values where not included in Java" 
    Date: Fri, 04 Feb 2005 21:55:41 -0800
To: Chris Smith <cdsmith@twu.net>

    Chris Smith wrote:
    > Apparently you haven't been reading the thread.

    you're right, sorry.

       Oracle's JDBC driver
    > should not be holding a ResultSet open across a Connection.close() --
    > nor a commit() unless a non-default holdability was set using JDBC3's
    > new overloads of createStatement and prepareStatement.

    I'll catch up on the thread. Is that happening?

    > Nor should it
    > survive a Statement.execute() or getMoreResults() (the version with no
    > parameters). If the Oracle driver is producing ResultSet instances that
    > survive these things, then it is in violation of the spec, including
    > (but not limited to) sections 10.1, 14.1.3, 14.2.5, Oracle's driver is
    > broken, and it's broken in a particularly gruesome way.

    I agree. When last I checked, the result sets that came from standard
    calls, such as executeQuery() *were* closed properly when the statement
    was closed or re-executed, but those result sets that arrived via
    non-standard JDBC, such as via output parameters of procedures,
    via their non-standard CallableStatement.getResultSet( int paramIndex)
    were not closed. A bug indeed, if it's still true. In fact the driver
    used to allow a user to execute a stored procedure via executeQuery()
    which must return a result set. The result set was some odd bogus result
    set that didn't relate to the procedure output.

    > The spec (somewhat confusingly, and for no good reason that I can see)
    > allows for greater leeway for Statement.close() -- requiring the driver
    > to immediately invalidate and "close" the ResultSet, but permitting it
    > to hold off on releasing resources until the next garbage collection.
    > That's not a particularly useful allowance, and I imagine that there are
    > probably no drivers that take advantage of it but still comply with the
    > spec. It appears that the author of the specification does not actually
    > understand garbage collection in Java. That theory is confirmed when
    > section 14.2.5 specifies that calling ResultSet.close() makes the
    > ResultSet object immediately available for garbage collection -- a
    > ludicrous requirement that invalidates the entirety of the Java security
    > model, and requires a heavily modified virtual machine to actually
    > implement correctly (luckily, no one actually takes this requirement of
    > the spec seriously).

    Yep, silly. I still have a reference to it. *Try* gc()'ing it...
    Even if it is closed and the reference is gone, until getMoreResults()
    is called, one could conceivably call getResultSet() again and expect to
    get the same already-closed result set, so the statement has to keep a
    reference for a while too.

    > Clearly that is in fact a JDBC issue, since it's about whether Oracle's
    > driver complies certain requirements of the JDBC specification or not.
    > If it is confirmed that this is a problem with Oracle's JDBC driver,
    > then apparently it will become necessary to make calls to
    > ResultSet.close() in the middle of a tight loop of PreparedStatement's
    > execute() calls. That would then be classified as a work-around for a
    > serious bug, *not* as good general practice for JDBC.

    I always close everything asap... Chaqu'un a son gout... but yes, I wasn't
    reading the thread.
    Joe Weinstein at BEA

  • Next message: Tor Iver Wilhelmsen: "Re: Why default parameter values where not included in Java"

    Relevant Pages

    • Re: JDBC and ResultSet problem
      ... Several MSSQL JDBC drivers employ the same scheme, they create multiple ... connections transparantly and use those for the multiple rowsets. ... extremely bitten by this behaviour once using the JTDS driver. ... I implemented the JDBC driver to ...
      (comp.lang.java.databases)
    • Re: MS SQL Server 2005 JDBC Driver Performance Issue
      ... the trace data records that approximately 50% of our CPU ... trace is recording CPU cycles 'twice' (once against the RPC and again against ... On to the v1.1 driver! ... link in the chain which is clearly the JDBC driver. ...
      (microsoft.public.sqlserver.jdbcdriver)
    • Re: MS SQL Server 2005 JDBC Driver Performance Issue
      ... the records are inserted at the rate of: 829.18 records/sec. ... We are now going to start end to end testing with the jTDS driver. ... link in the chain which is clearly the JDBC driver. ...
      (microsoft.public.sqlserver.jdbcdriver)
    • Re: Is perl better? :(((
      ... > Apparently you haven't been reading the thread. ... Oracle's JDBC driver ... such as executeQuery() *were* closed properly when the statement ... > If it is confirmed that this is a problem with Oracle's JDBC driver, ...
      (comp.lang.java.databases)
    • Re: copy data from one database to another
      ... That depends on the driver. ... Some drivers are caching the full result in memory before returning from executeQuery() (such as Microsoft's JDBC driver and jTDS) other drivers only load a row each time ResultSet.nextis called ... But the Microsoft driver and jTDS can be configured to not cache the full result set ...
      (comp.lang.java.databases)