Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Date: Thu, 14 May 2009 13:48:36 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Unexplained exception: temp file cannot be found
In-reply-to: <gugmbp$54a$1@ger.gmane.org>
Sender: Knut.Hatlen@Sun.COM
To: Derby Discussion <derby-user@db.apache.org>
Message-id: <wjo8r5yrucq3.fsf@sun.com>
Organization: Sun Microsystems
References: <guee68$ove$1@ger.gmane.org> <x1oxfxf84csu.fsf@sun.com>
 <gugmbp$54a$1@ger.gmane.org>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.93 (usg-unix-v)

Tim Dudgeon <tdudgeon@informaticsmatters.com> writes:

> Dag H. Wanvik wrote:
>>
>> It looks as if the creating of a temporary file failed. Does the path
>> exist
>> (C:\Users\Csizi\Documents\IJCProjects\ijc-project\.config\localdb\db\tmp),
>> and if so, is it writable for this account?
>>
>> Dag
>>
>
> Yes, the user has confirmed that this directory does not now exist:
> C:\Users\Csizi\Documents\IJCProjects\ijc-project\.config\localdb\db\tmp
>
> but that its parent directory does exist, and does have write access
> (but this is Vista so strange things could be happening!).
>
> I would imagine that the tmp directory would be created automatically
> by Derby when it needed it. It is not normally present.

Yes, there is code that's supposed to take care of that right before the
code that fails, and it's supposed to throw an exception if the
directory cannot be created. Perhaps there's something that's removing
the directory (but I didn't think Derby would remove the directory
except when performing a clean shutdown of the
database).

FileNotFoundException is the only kind of IOException RandomAccessFile's
constructor is allowed to throw, and the javadoc states that it can be
thrown "(...) or if some other error occurs while opening or creating
the file", so the problem could really be anything I/O-related.

> What would the cause of generating the temporary file?

The stack trace indicates that this happens during a cascading delete
operation (deleting a row that is referenced from another table with ON
DELETE CASCADE). For this kind of delete operations, Derby uses deferred
deletes and needs to keep a list of rows to delete until it's ready to
perform the actual deletion. The list of rows is kept in a temporary
conglomerate/file.

-- 
Knut Anders