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 <[email protected]>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 < >> [email protected] <mailto:[email protected]>> 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
