db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Clary" <jcl...@actuate.com>
Subject RE: Possible problem in org.apache.derby.impl.store.access.BackingStoreHashTableFromScan
Date Fri, 16 Mar 2007 19:35:29 GMT
Thanks, Dag.

I've added a JIRA bug, and attached the test program demonstrating the
issue.  We also are testing a patch that propagates holdability from the
activation (very similar I bet ;-), but are also worried about side
effects.  I'd be interested in hearing about your experience.  

-----Original Message-----
From: Dag.Wanvik@Sun.COM [mailto:Dag.Wanvik@Sun.COM] 
Sent: Friday, March 16, 2007 12:24 PM
To: derby-dev@db.apache.org
Subject: Re: Possible problem in

Jeffrey Clary <jclary@actuate.com> writes:

> I'm new to Derby and to these lists, so I'm not sure what I am
> is a bug or expected behavior.  You can see an earlier question I
> on the derby-user list 3/15/2007 titled "Heap container closed
> (2 statements on same connection)."

I think this must be a bug.  Like you noted, the backing store for the
hash table used here is opened without setting the keepAfterCommit,
which is needed with holdability. I made a trial patch to propagate
this setting down from the activation, and the test works, but I don't
know about any possible side effects.

Does anybody know a reason for the comment on this line of code in
BackingStoreHashTableFromScan.java:101 ?

line 101 >  false /* Do not keep the hash table after a commit. */);

I know we keep a hash backing store table across commits already in
the case of insensitive scrollable result sets; here is is used to
back up a hash join.

I'll try to run the regression test with the patch and see if it blows

You may file a JIRA bug issue for this if you like, or, if you prefer,
I can do it.


> I am not seeing the behavior I would expect after calling
> Connection.setHoldability(ResultSet. HOLD_CURSORS_OVER_COMMIT).   I
> attached a test program that displays the behavior.  Here is an
> of what happens (with autocommit on):
> 1.       Execute a statement that returns a fairly large result set.
> 2.       Execute another statement on the same connection that
> does not affect the first result set, but that does update the
> 3.       Iterate through the first result set.
> 4.       After some number of calls to next(), take an exception
> indicating "heap container closed."
> I have looked a bit into the Derby source code, and I think that the
> issue is related to the
> org.apache.derby.impl.store.access.BackingStoreHashTableFromScan
> constructor.  It passes a constant false value to its super in the
> keepAfterCommit argument.  In fact, there is a comment there that says
> "Do not keep the hash table after a commit."  It seems to me that this
> value should be based on the holdability attribute of the statement,
> set in the connection or when the statement is created.  But knowing
> little about the Derby implementation I don't have any idea whether
> would trigger some unintended consequence.
> Any advice would be appreciated.
> Thanks,
> Jeff Clary

Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax:  +47 73842101

View raw message