Re: Is perl better? :(((
From: Joe Weinstein (joeNOSPAM_at_bea.com)
Date: 02/05/05
- Next message: Chris Smith: "Re: Is perl better? :((("
- Previous message: Chris Smith: "Re: Is perl better? :((("
- In reply to: Chris Smith: "Re: Is perl better? :((("
- Next in thread: Chris Smith: "Re: Is perl better? :((("
- Reply: Chris Smith: "Re: Is perl better? :((("
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: Chris Smith: "Re: Is perl better? :((("
- Previous message: Chris Smith: "Re: Is perl better? :((("
- In reply to: Chris Smith: "Re: Is perl better? :((("
- Next in thread: Chris Smith: "Re: Is perl better? :((("
- Reply: Chris Smith: "Re: Is perl better? :((("
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
