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.
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
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@example.com <mailto:firstname.lastname@example.org>> 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.
David W. Van Couvering