Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Message-Id: <6.2.3.4.2.20051016231519.039dd640@pop.rcn.com>
Date: Sun, 16 Oct 2005 23:32:45 -0700
To: "Derby Discussion" <derby-user@db.apache.org>
From: Jeffrey Lichtman <swazoo@rcn.com>
Subject: RE: Error 38000 with a stack overflow on recordset.next()?
In-Reply-To: <411004C89F48004A9B41C341A515E7BA01530B8C@mail.oit.docfinit
 y.com>
References: <411004C89F48004A9B41C341A515E7BA01530B8C@mail.oit.docfinity.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed


>I start out by running the following prepared statement a few thousand
>times:
>
>INSERT into existingfiles (path, id) VALUES (?, ?)
>
>Where path is a windows file path and id is an integer.  I clear out the
>parameters with clearParameters() after each insert and set them to new
>values.  Then I close and null out the statement.
>
>After that I create another prepared statement that looks like this:
>
>INSERT INTO filesystemfiles (path) VALUES (?)
>
>And run it a few hundred to a few thousand times with a string argument
>in the form of a Windows file path.  After that I close it and move on
>to this select statement:
>
>SELECT path from filesystemfiles where path not in (select path from
>existingfiles)
>
>I've run this as both a Statement and a PreparedStatment.  I then get
>back the ResultSet.  Things blow up when I try to run next() on it.  The
>only thing that I can think is that the query using a subselect and two
>large tables may be hosing up the Derby code.  Let me know if you need
>anything else.

The interesting thing about this is that the stack overflow is in 
UnionResultSet.openCore, yet what you describe here has nothing to do 
with unions. There's nothing in the language code that I know of that 
would introduce a UnionResultSet into any of these statements.

I suspect the real problem is with one of the INSERT statements. 
Cloudscape allows the VALUES clause on an INSERT to have more than 
one row. When you do this it represents it internally as an insert of 
a multi-way union of rows with constants in them. If your code put 
together an INSERT/VALUES with 100,000 rows, Cloudscape would 
represent it as 100,000 nested UnionResultSets. This could easily 
cause a stack overflow of the type you're seeing.

Now, what I've described here doesn't match what you've described for 
your code, but is it possible your code doesn't do exactly what you 
think it does?

I suppose the potential stack overflow from a huge VALUES clause 
could be considered a bug, although I don't know how important it 
would be to fix it. The most obvious fix would be to introduce a 
ValuesResultSet that iterates over a set of constant rows and a 
corresponding ValuesNode, and to change the parser so it generates a 
ValuesNode instead of a set of UnionNodes.


                        -        Jeff Lichtman
                                 swazoo@rcn.com
                                 Check out Swazoo Koolak's Web Jukebox at
                                 http://swazoo.com/