commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cservenak Tamas <>
Subject Re: [transaction] FileNotFoundException during commitTransaction()
Date Tue, 22 Nov 2005 18:31:34 GMT
Hi Oliver!

I'm am positively sure about #2. I have NO ACCESS to FS except thru FRM.
And plus, the whole txfs/store and txfs/work (the store and workdir of
FRM) is isolated, it is not used by direct File access.

(second para) Not quite. This error happened on any stage (i have 4 of
them) on OUTPUT side of it. The error happened on the side where we are
PLACING files, not taking.

To clear this up:

One Stage works like this:

doBeforeTx() {
  resId = queue.get();


doInTx() {
  frm.readResource(INPUT_PREFIX + resid);
  do smthng with resId over frm,
  frm.writeRes( OUTPUT_PREFIXresId)


doAfterTx() {

INPUT_PREFIX and OUTPUT_PREFIX are not constants actually, they are set
up on startup. The materialization of this is like series of dirs, and
files are travelling from dir to dir, as they advance from stage to stage.

So, the error always happens on the LEFT side (while commit - write) of
files, not RIGHT side (read). As pseudocode says, the RIGHT side even
does not know about the resId (it is not sent over queue!).....

Remember, it dies in

new FileOUTPUTStream(File)...

The exact location will be in stack trace....

Stack trace follows in a moment.


Oliver Zeigermann wrote:
> Hi,
> I looked at the code of commit and it really looks ok. Is it always
> the same file (or same category of file) that is not found?
> FileHelper.moveRec is only called from inside of
> TransactionContext.commit which is synchronized on the context. This
> means if a file that should be there no longer exists has  probably
> been deleted in between finding the children of a folder and iterating
> through it. This can only be done by a second thread which should not
> have any access to the directory of this transaction.
> Note #1: That two transactions running on the same store dir can not
> interfere while committing as this is prevented by locks.
> Note #2: No other process/thread/whatever may access the store
> directory that FRM is working on.
> Are you sure that #2 is guaranteed in your application?
> Oliver

View raw message