I am sorry to say I didn't save the database directory and have since worked around the problem by checking to see if the table exists before creating it, so I don't know the names of the files.  If it's important, I'll comment out my changes for now and recreate the problem and tell you what I'd see.  

However, it definitely never got cleaned up.  Our QA person had his system up for a few days and it went from a few MB to 5GB and never went back down.  Shutting down and rebooting the database also had no effect.  The only time I ever saw it shrink back down was when I upgraded from 10.4 to 10.5

David

On Mon, May 3, 2010 at 2:25 PM, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
what are the names of the new files after the transaction that
tried to create the existing table them commits?  If they are still c*.dat then there
is definitely something wrong.  If they start with a different letter
then it could be that derby is acting as expected and just did not get around to cleaning them
yet.  I believe it does this at checkpoint time.  The assumption being
that normally this case is just drop table and not needed to be optimized.

I have not looked at the code but my guess is that create table is
counting on a unique key violation to tell whether a table exists
or not.  To do this it has to do an insert and to do the insert it
needs the name of the file which only exists after the file is
created.

David Van Couvering wrote:
Yes, it does sound like a bug.  I'll log a JIRA

On Fri, Apr 30, 2010 at 6:50 PM, Bryan Pendleton <bpendleton.derby@gmail.com <mailto:bpendleton.derby@gmail.com>> wrote:

       As I mentioned to Knut, I try to issue a CREATE TABLE each time
       I connect, and ignore the exception saying it already exists if
       the table is already there.  

   If this is leaking a conglomerate each time (creating a .dat file but
   never deleting it), that seems like a bug to me.

   thanks,

   bryan




--
David W. Van Couvering

http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering




--
David W. Van Couvering

http://www.linkedin.com/in/davidvc
http://davidvancouvering.blogspot.com
http://twitter.com/dcouvering