Use NIO for file copying/moving

• Key: TRANSACTION-12
• Type: Wish
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Holger Hoffstätte
• Affects Version/s: 1.2
• Fix Version/s: 2.0

Description

The Mule project (http://mule.codehaus.org/) is considering adoption of commons-transaction for (among other things) file transactions. Unfortunately inspection of the code reveals that FileHelper copies files in the slowest possible way (traditional Java I/O via Input/OutputStreams). Since some of our users move lots and/or large files (hundreds of megabytes to gigabytes) we implemented file moving by rename (atomic and obviously very fast when source and target are on the same filesystem) and NIO as backup strategy (a lot less CPU usage).
Attached is a code snippet that outlines the procedure; it would be cool if c-tx could adopt a similar strategy for moving via rename-first and copy via NIO. I do not know if and how this might conflict with c-tx's "transactional" behaviour and recovery but then again it is just a suggestion.

Comments

[Oliver Zeigermann]

Renaming (rename-first as you call it) is already done by the current implementation.

The current fall back strategy is used as commons transaction only requires Java 1.3 which does not support NIO. It might be an option to have different implementations for pre 1.4 and post 1.4 JDKs though. Could you think of something like that?

[Holger Hoffstätte]

Thanks for feedback - I didn't realize you were shooting for compatibility with JDK 1.3 (bummer or that you already did rename-first (good to know). It's not a dealbreaker since adoption of c-tx is still some way off; when the time has come we may think about providing something like a pluggable FileHelper as extension/patch.

[Jörg Heinicke]

For the moment I'd postpone this one after a possible refactoring. But if you provide a more or less backwards compatible way it can go into an earlier release as well

[Oliver Zeigermann]

Copying and moving not benefits from NIO.