commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject Re: [vfs] proposal: FileUtils
Date Wed, 02 Feb 2005 22:08:47 GMT
B. K. Oxley (binkley) wrote:
> I'm curious what you find out about Commons Transactions.  When I 
> looked  it over, it seemd to me designed with primitives for us to use 
> to make our own transactions.  I missed any ready-to-use code for this 
> purpose. 
After 2 hours of copy/paste their FileResourceManager to use 
vfs.FileObject only I am able to do such thing:

// init phase
        String tx1 = "tx1";
        VFSResourceManager rsm = new VFSResourceManager(
            "/home/im/tmp/tx/store", // <= root filesystem where the 
real stuff should happen on commit
            "/home/im/tmp/tx/work", // <= work filesystem - could be 
different to store above
            new PrintWriterLogger(new PrintWriter(System.err), "VFS", true),
// start transaction
// create file1
        rsm.createResource(tx1, "dir1/file1.txt");
// create file2
        rsm.createResource(tx1, "dir2/file1.txt");
// write into file1
        OutputStream os = rsm.writeResource(tx1, "dir1/file1.txt");
// delete file2
        rsm.deleteResource(tx1, "dir2/file1.txt");
        rsm.deleteResource(tx1, "dir2"); // <= dir2 has been created by 
the above createResource - now we have to remove it here manually.
// commit transaction

Now - whats missing in this example? .... right .... there is no "move" 
or "rename" operation.

*) implement rename
*) implement something like listResource(tx) where we could get a list 
of all files in an directory - including/excluding those created/deleted 
within the transation.
Both need some more investigation to see how this could happen.

After experimenting a little bit it is fantastic to see who it prevents 
two simultan transactions to create the same file - in fact it isnt 
prevent - the second transaction just waits until the first has finished 
and then the second gains the lock.
So we get in-process locking for free.
The above code is just a start, but think of a file-object where the 
transactional logic is encapsulated and one can do whatever he wants - 
it will only be represented on the filesystem if commit() has been called.

FileObject foRootTransactional = VFS.getManager().beginTransaction(foRoot)
for (child .. foRootTransactional.getChildren())

And maybe if your RamFS comes to reality we could use it as work-space 
e.g. if we know we handle only small transactions.

I am looking forward to read what you think about it.
If you would like to experiment a little bit follow the instructions at


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message