commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Heinicke (JIRA) <>
Subject [jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
Date Wed, 25 Jul 2007 17:45:31 GMT


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 (
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 (, 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
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?


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:
>             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:
> 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:
For additional commands, e-mail:

View raw message