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
                                [EMAIL PROTECTED]
                                Check out Swazoo Koolak's Web Jukebox at
http://swazoo.com/

Reply via email to