[
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515362
]
Jörg Heinicke commented on TRANSACTION-9:
-----------------------------------------
1. IMO considering 2PC is a must. You can't add this simply in a locally
extended version. And not being able to use ctx in distributed transaction is a
major limitation. ctx 1.2 supports this as well with the prepare method.
2. About the strategies: In ctx 1.2 strategy 2 is implemented - and commits can
fail. The FileResourceManager assumes to be in inconsistent state in this case
and you need to solve the issues by hand and restart it. A major pain in server
environment. This happens for example if an external process holds a lock on a
file. I also wonder if you can check everything in prepare() (at the moment
prepare checks actually nothing) since a commit MUST neither fail if there was
a positive outcome of prepare. A failing rollback is of course bad as well. I
mean, hey, actually the sense of transactions is to assure that none of both
fails. So it should really be no either-or decision for the user which strategy
to use.
I wonder if you can prevent external processes from locking a file by getting a
lock on it yourself. What about FileLock? I have no experience with it, but the
Javadoc says: "This file-locking API is intended to map directly to the native
locking facility of the underlying operating system. Thus the locks held on a
file should be visible to all programs that have access to the file, regardless
of the language in which those programs are written." But it also talks about
system dependency and especially programs not following the protocols
(http://java.sun.com/j2se/1.5.0/docs/api/java/nio/channels/FileLock.html). But
that's behind our scope then anyway.
If there is really no way to make both commit and rollback fail-safe I think we
should think about what's happening more likely to decide for the one or the
other option (if both strategies are implemented the default strategy). Such a
lock issue as I observed it with the current implementation seems to be more
likely than a rollback failure. What are actually the potential problems
resulting in the latter except a major system failure? All other operations
have been done already. Why should it not be possible to move a copy back to
its original place? I can't think of a problem with standard file system
operations like locks or write protection what can happen with strategy 2.
3. I don't consider "Direct access to the destination folders sees the changes
immedeately" an issue. It's "their" fault, not ours. They do not know about our
transactions anyway.
4. Regarding the Resource/ResourceManager interface:
Filtering: No, I have no code yet for the filtering. But it's only delegation
to the list(Files) methods in java.io.File
(http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html), so it should be
trivial. The thing was only that we abstract from File to Resource, so we
should also abstract from File(name)Filter to ResourceFilter (I'd prefer merge
of both FileFilter and FilenameFilter as
http://jakarta.apache.org/commons/io/api-release/org/apache/commons/io/filefilter/AbstractFileFilter.html).
In a default implementation it gets an instance of one of those filters and
just delegates to them.
FileResource vs. DirectoryResource: I wonder in which way this causes problems
and creates the need for castings? Isn't it that what the interface is about?
The only code being aware of it is the instantiation code in
ResourceManager.get(File|Directory)Resource(..) in my proposal, isn't it?
Joerg
PS: Using Jira is somewhat nasty to use for discussion. But I understand the
mailing list is as well because of the high traffic. Hopefully they split it up
anytime soon (separating Jira and commit messages).
> [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]
