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
