commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Zeigermann" <>
Subject Re: [transaction] splitting ResourceManager interface
Date Fri, 14 Jul 2006 20:52:47 GMT
Hi, Jörg!

That certainly is post 1.2, right? Maybe even some work for a 2.0
version? More details inline.

2006/7/14, Joerg Heinicke <>:
> Actually I would like to address some different requirements with my
> FileResourceManager, which I can no longer fulfill by just extending the current
> one. Reimplementing the current ResourceManager interface would be absolute
> overkill as the transactional stuff is exactly the same. It's only the resource
> handling I need in a different way.
> My use case: We have some data input and output dirs for different let's call
> them communication partners and a common repository dir:
> ROOT -- cp1 -- upload
>      |      \- download
>      |- cp2 -- upload
>      |      \- download
>      |
>      \- repo
> Up to now the data dirs and the repo dir had a common root to which I set the
> store dir. But now data dirs and repo dir can be completely different. I could
> set the store dir to "/" but I don't think that's really appropriate.
> Furthermore the FileResourceManager does a recursive delete of directories so
> that the data dir structure gets lost atm. With the current behaviour I would
> need one FileResourceManager for every sub dir. This would be acceptable if they
> had not such a huge overhead of lifecycle but would only be wrappers around file
> system access. All instances would refer to one TransactionManager then. Another
> possibility would be to allow the FileResourceManager to handle multiple store
> dirs but I'd prefer the first approach.

Hmmm. Why do you need FileResourceManagers in the fist place? Just to
synchronize file access? Not quite sure here...

Anyway, TransactionManager wouldn't be such a good name for a new
class as it has a predefinied meaning in the J2EE world I guess.

> > Anyway, if you want to introduce something new, got ahead, but be
> > aware of backward compatibility issues.
> The question is in which extend. Even simply stripping the transactional concern
> from ResourceManager interface into its own and letting the FileResourceManager
> implement both interfaces, can lead to incompatibilities if the methods for
> transactional concern are called on the ResourceManager interface and not on the
> FileResourceManager instance.

One way would be to leave the ResourceManager interface untouched and
introduce your two new interfaces. FileResourceManager would implement
all three interfaces.

Another idea would be to make it all better in 2.0 and do not care too
much for backward compatibility. One idea might be to even use Java 5
locking. Maybe this is stuff for another thread, though...


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message