db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bergquist, Brett" <BBergqu...@canoga.com>
Subject RE: Question on unloading in an embedded environment
Date Wed, 17 Aug 2011 14:52:24 GMT
Here is the whole application.  It is still in a rough format but on a smaller database it
does indeed work correctly.  The only thing that it cannot do when copying the database is
handle GENERATED ALWAYS columns.  For these, it turns them into GENERATED BY DEFAULT and as
the last step determines the next value to use and issues an ALTER TABLE statement to reset
the next generated value.

It would be useful to somehow allow the SYSCS_IMPORT_TABLE to bypass the constraint that a
GENERATED ALWAYS column cannot be inserted with a value or have the ability to change the
column type back to GENERATED ALWAYS after the determining the correct next value.

-----Original Message-----
From: Bryan Pendleton [mailto:bpendleton.derby@gmail.com] 
Sent: Wednesday, August 17, 2011 9:40 AM
To: derby-dev@db.apache.org
Subject: Re: Question on unloading in an embedded environment

> Instance Counts for All Classes (excluding platform)
> 38006784 instances of class org.apache.derby.impl.store.access.sort.Node

One possibility is that the sorter is confused about how much memory
is available.

The sorter is very clever, and tries to figure out whether it can perform
the sort in-memory, or whether it has to switch to an external (disk-based)
sort, using temporary files to hold the partially-sorted data.

If the sorter is confused about how much memory is available (i.e., thinks
there is more memory available than there actually is), then it might
drive the system out of memory.

This would certainly be a bug, but not a leak exactly, rather a flaw
in the internal-vs-external sort analysis code.



P.S. I'm still wondering if your memory issues are actually external to
Derby; that is, if you've configured your JVM with memory sizes that exceed
the memory available in the underlying operating system. That would cause
Derby to attempt to allocate data structures that the JVM was willing to
allow, but which the underlying OS refused to provide.

View raw message