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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
