commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Fassev (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
Date Wed, 25 Jul 2007 18:29:31 GMT

    [ https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515376
] 

Peter Fassev commented on TRANSACTION-9:
----------------------------------------

1) FYI: The implementation I have already attached to this Issue DOES solve the problem of
failing of a commit. All primitive actions, like "create", "move/rename", "delete", "overwrite/append"
have  "do()" and "undo()" methods, which allows to rollback the transaction at any time, even
after an error during a commit or after prepare commit. So we can implement a two phase commit
and support distributed transactions. But a rollback (after a commit/prepare commit has bee
started) currently may fail (and must be fixed) because of:

a) There is not enough free space, for instance because the temp-transaction directory (where
the undo files have been copied), is on a different volume.
b) An external process is accessing a committed file (for instance a backup), and the rollback
can not delete or rename or delete the already committed file.

What we can do:
a) Create a temp-directory at each volume, and create a shadow copies only on the same volume.
Here we have to support a multiple temp directory for a single transaction.
b) Actually, we can only wait (in a separate thread may be) for the external process to end
and to rollback the transaction. But we have to hold the locks until the full rollback is
completed and throw a Lock-Timeout exception, if somebody whants to access the resources in
the mean time. Or we have to use FileLocks, to prevent exterenal access to the changed transaction
files.

So I think, we can manage it and create a secure transactional file access, even without a
FileLock synchronization. But if FileLocks do really work, why not use them? This may be also
an option, which may be chosen by the user.

4) Filtering: It is correct, we don't need to know about filtering, but FYI there is a Jakarta
Commons IO library at Apache, which contains a set of file filter.


> [transaction] Add full file management capabilities to the FileResourceManager
> ------------------------------------------------------------------------------
>
>                 Key: TRANSACTION-9
>                 URL: https://issues.apache.org/jira/browse/TRANSACTION-9
>             Project: Commons Transaction
>          Issue Type: Improvement
>         Environment: Operating System: All
> Platform: All
>            Reporter: Peter Fassev
>            Assignee: Oliver Zeigermann
>            Priority: Minor
>             Fix For: 2.0
>
>         Attachments: filemanager.zip
>
>
> Hi,
> As stated in the doc the FileResourceManager is:
> "A resource manager for streamable objects stored in a file system"
> I agree, that this is a resource manager, but it could be easily extended, to 
> support a full file management system. It will be very helpful to have 
> additional methods like renameResource(), getResourceSize(), getResourceTime(), 
> setResourceTime() etc. This are common file operations, which should be managed 
> by the FileResourceManager.
> Further it will be very helpful to have (real) support for resource collections 
> (folders). It will be necessary to distinguish between single resources (files) 
> and collections (folders). 
> Together, this features will enable a transactional access to any file based 
> resources - for instance a document repository.
> Are there plans for such extensions and if not, will they actually fit in the 
> goals of the transaction library?
> If not, please open the underlying structure, like the inner class 
> TransactionContext, in order to add extensions the file management. For 
> instance, it will be good to have a separate factory method, which creates the 
> context.
> If you are interested in this proposal, I am ready to contribute to this 
> project. I consider myself as an experienced java developer and I will be glad 
> to help you. 
> Best regards
> Peter Fassev

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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


Mime
View raw message