[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514744
]
Peter Fassev commented on TRANSACTION-9:
----------------------------------------
Thinking about it, there is not so match difference between the two scenarios:
1) Work with the original files, which means creating undo copies - deleting
all undo files after commit
2) Work on the copies only, which means creating copies and working on them -
deleting the original files and moving/renaming the modified copies on commit
During the both scenarios we should make copies before each change, which I
think is the longest operation. Deleting and moving files are actually a very
fast. During the commit operation in the second scenario we also have a
uncomplete state of the original files.
The only advantage of scenario 1) is that on commit only the copies have to be
removed. BUT, some system may use distributed transactions (i.e.
synchronization with a DB-transaction), which means we have to think about
tryCommint, and rollback after tryCommit if the distribute transaction fails.
In such scenario, it is not acceptable, that the rollback fails.
The question is, why a rollback in scenario 1 can fail (which is the same for
commit in scenario 2)? As far as I can see, this could happen:
a) If there is not enough free space on the disk and if we are moving files,
this could happen only if the working temp directory is not on the same disk or
when the repository spans more than one disk.
b) If an external process (for instance a backup) is accessing the files
directly. That's why direct access should be somehow synchronized in both
scenarios.
If somebody is using distributed transactions, may be the scenario 2 has an
advantige. When the file transaction is committed as the last one in the queue.
If the DB-Transaction fails, we have to delete only the copies, the rollback
can not fail.
So I think it depends on the application and on the usage of the file
transactions. How about implementing both scenarios? For instance my
implementation (which is attached here) is using the second scenario, where the
actual file management actions are separated from the transaction facade. The
actions are very simple. I think it will be very easy to implement the scenario
1) in the same way under a different TransactionContext interface and let the
user decide, which one he wants to use.
> [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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
