Nelis Bijl wrote:
>
> Hi,
>
> A MOVE request is handled by Macro.move which performs a copy followed
> by a delete.
> This has the following drawbacks:
> - The underlying store might provide an API for moving that is much
> faster. In unix terms:
> moving an INODE is much faster than copying a complete sub-tree and
> deleting the source
> afterwards. I would suggest adding 'moveXxx' methods to the various
> store interfaces just like
> 'createXxx', 'retrieveXxx', 'storeXxx', etc. (the default
> implementation could still be copy followed by
> delete).
> - The permissions for deletion are checked after the copy operation.
> This means that you need to
> wait for the full copy operation (and it's rollback) before an error
> response is sent.
>
> A DELETE request is handled by Macro.deleteObject which performs a
> recursive delete of the complete sub-tree.
> Just like with MOVE the underlying store might have a direct API that
> performs a recursive delete.
These are good ideas (they're things that are needed for high
performance, although the main performance bottlenecks are elsewhere
right now (they're pretty big bottlenecks too)), but it's harder than it
looks because of how generic the store interfaces are - I suspect that
half the stores would end up having to implement it just as a copy then
delete anyway.
However, I'm with you on (at least) the move change (delete is just an
optimisation, so it's less critical, I think) - without this many of the
stores will be unable to meet the requirements of webdav (notably: a
move must be an _atomic_ copy-then-delete. Full transaction support
allows the database-backed stores to work ok for this, but file-based
stores will fail (that is, _cannot_ be made to work reliably on most
filesystems, and certainly cannot be made to work reliably given the
limitations of java's file-access APIs) unless we just lock all
concurrent store access (again, that won't have a big performance impact
right now, but it will once other things are more optimised).
Michael
