Bug 109042 - Invalid Connection objects when DataQuery.close() is not called
Invalid Connection objects when DataQuery.close() is not called
Status: CLOSED RAWHIDE
Product: Red Hat Web Application Framework
Classification: Retired
Component: persistence (Show other bugs)
6.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Archit Shah
Jon Orris
:
Depends On:
Blocks: 100952
  Show dependency treegraph
 
Reported: 2003-11-04 11:47 EST by Carsten Clasohm
Modified: 2007-04-18 12:59 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-12-10 11:52:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Server log (4.74 KB, text/plain)
2003-11-04 11:50 EST, Carsten Clasohm
no flags Details
JSP to reproduce the bug (968 bytes, text/plain)
2003-11-06 09:00 EST, Carsten Clasohm
no flags Details

  None (edit)
Description Carsten Clasohm 2003-11-04 11:47:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925

Description of problem:
When not all results are retrieved from a DataQuery with next(), and
close() is not called,
com.redhat.persistence.engine.rdbms.ResultCycle.finalize() can close
the database Connection when it is invoked. This results in a
"java.sql.SQLException: Connection has been closed" when another
thread is currently using this connection.

See the attached log for an example where a thread gets a Connection
object, the finalizer thread closes that Connection object, and the
first thread dies with an exception trying to use the Connection it
just got.


Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
This is hard to reproduce because garbage collection is unpredictable.
But on a customer's development system, the error could be reproduced
by clicking around in the UI for some time.

1. Call DataQuery.next() for a result set with more than one row
2. Don't call close(), but make sure that the JVM can garbage collect
the DataQuery object (by using a local variable). 
3. Do some more work, including database accesses.


Expected Results:  Either the ResultCycle finalizer should not close
the Connection, or it should make sure that the connection is not used
before closing it, or we should update the DataQuery documentation and
tell people that close() *has* to be called when not all rows are
retrieved. The latter is what I have done for now.


Additional info:

This happens with the 6.0 code from Perforce. It did not happen with
the release version of 6.0. (Although one cannot be sure with an error
which depends on a certain object being garbage collected at a certain
time.)
Comment 1 Carsten Clasohm 2003-11-04 11:50:25 EST
Created attachment 95714 [details]
Server log

Example of how the finalizer thread closes the connection used by another
thread.
Comment 2 Carsten Clasohm 2003-11-06 09:00:42 EST
Created attachment 95759 [details]
JSP to reproduce the bug

Actually, the bug is easy to reproduce, thanks to System.gc() and
runFinalization(). See the attached JSP.

Note that the "Connection has been closed" exception you will get comes from
the BaseServlet class. That's because it tries to abort the transaction after
catching the exception thrown in the JSP, and while doing so, throws an
exception itself. If you comment the "transaction.abort()" in
BaseServlet.internalService(), you will get the original exception from
stmt2.execute.

Another interesting thing about the JSP is the behaviour when you add a call to
users.close() or remove the if block altogether. In this case, you will get a
null pointer exception in the finalize method of _test_22dfinalize__jsp. Not
sure why that happens.
Comment 3 Richard Li 2003-11-06 09:04:07 EST
carsten: is this project-critical? we're aggressively triaging for QU,
so target for 6.0.2 unless you say otherwise.
Comment 4 Carsten Clasohm 2003-11-06 09:17:36 EST
No, it is not project-critical. We have added close() calls for all
DataQuery objects where we don't retrieve all rows.
Comment 5 Carsten Clasohm 2003-11-07 11:33:12 EST
Unfortunately, fixing this by adding close() calls did not work as
well as expected. We still encounter the error sporadically, and have
enabled debug logging for ResultCycle to track down the places where
DataQueries are not closed. But that's a slow process.

It would really be helpful if this bug were fixed in the persistence
layer.
Comment 6 Richard Li 2003-11-07 15:03:00 EST
In theory, this shouldn't be happening.

In practice, it is. Retarget based on Carsten's comments for 6.0.1,
but need to investigate and determine what the root cause is before
deciding whether or not a fix can be done for 6.0.1.
Comment 7 Carsten Clasohm 2003-11-13 01:15:06 EST
Changes which add close() calls to core and cms code: 37948, 37950
Comment 8 Archit Shah 2003-11-21 12:03:13 EST
This bug was caused by faulty integration from dev to 6.0.x. Change
36462 on 6.0.x added result set closing functionality that interacted
poorly with the com.arsdigita.db.* jdbc wrappers that did the same
thing . Change 38190 reverts 36462. The test jsp works now.

Note You need to log in before you can comment on or make changes to this bug.