commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "B. K. Oxley (binkley)" <bink...@alumni.rice.edu>
Subject Re: [vfs] proposal: FileUtils
Date Fri, 21 Jan 2005 22:49:44 GMT
Mario Ivankovits wrote:
> About transactionality :- care should be taken to not reimplement 
> something like [transaction], they already implemented such a beast 
> using java.io.File. Maybe we can adopt it.

I'll have to look at it, but it looked like overkill for what I had in mind.

I've been toying with closure-like operations to take care of this, so 
that saving from an input stream with a backup looks like:

FuFile newContent = new FuFile(newContentStream);

new Move(backup, backup.createTemporary(),
     new Move(original, backup,
         new Move(newContent, original, Noop)))

The bulk of Move is:

public void eval() throws FuException {
     try {
         original.moveTo(newLocation);
         nextMoveClosure.eval();

     } catch (FuException e) {
         newLocation.moveTo(original);
         throw e;
     }
}

This means that you try to rename the original, call the next operation 
and if that fails, undo the rename.  It's a poor-man's transaction.

If you look at the nesting of my first code snippet, it behaves like this:

1. Write the content to a temporary.
2. Move the backup to a temporary to recover the backup if other 
operations fail.
3. Move the original to the backup to recover the original if other 
operations fail.
4. Move the content temporary to the original.

The only complication I didn't mention is that my actual code takes care 
of deleting the various temporaries when things fail or they don't.

Another way to view this is that I took:

try {
     doTryWork();

} catch (e) {
     doCatchWork();
     throw e;

} finally {
     doFinallyWork();
}

And made each of the "do work" methods a closure object with an eval() 
method to invoke them.


Cheers,
Brian

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message