You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Joerg Heinicke <jo...@gmx.de> on 2006/07/13 17:56:47 UTC
[transaction] splitting ResourceManager interface
Hello,
the more I work with the FileResourceManager the more I'm convinced that the
ResourceManager interface should be splitted into two interfaces: one for
handling the locking and transactional stuff (proposal: TransactionManager) and
one for actually handling the resources (as is: ResourceManager).
One the one hand the only implementation, the FileResourceManager, simply does
too much, i.e. too many concerns are handled in it. On the other hand I extend
my local version of the FileResourceManager with more and more methods to
emulate a file system access (methods from java.io.File actually). In theory I
would need to add these methods to ResourceManager interface to be able to work
with interfaces, but it would get bigger and bigger.
Instead I wonder if a generic ResourceManager interface (in my new sense as
described above) is appropriate at all. Probably it would be more appropriate to
rename it to FileResourceManager or introduce FileResourceManager interface
extending ResourceManager. The splitting of the current ResourceManager
interface would allow to reuse the transaction/locking capability with different
ResourceManagers (in my new sense).
The splitting should be quite easy IMHO. The concerns are quite good separated
in the FileResourceManager.
WDYT?
Regards,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [transaction] splitting ResourceManager interface
Posted by Oliver Zeigermann <ol...@gmail.com>.
2006/7/15, Joerg Heinicke <jo...@gmx.de>:
> (OT: Sometimes ago I mentioned that this XAResource implementation might be
> donated to Commons Transaction. I got no go from my employer at that time. We
> were taken over by another company and our management did not want to decide
> about those things. Maybe I should put it back on the table ...)
Nice idea. I think that would be a valuable contribution.
> > 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.
>
> Ok, naming clashes might better be avoided. But from the meaning I chose the
> name after comparing with the JTA TransactionManager interface as the
> ResourceManager's methods related to transaction handling and the JTA
> TransactionManager methods are quite similar. So I don't think there is a
> different meaning. And how many ResourceManagers exist in the world? ;)
Hehe, right...
> About Java 5: I have never used it yet. Don't know what it can really buy us
> though I read much about its nice features.
I would buy us the new concurrent package which has taken over Doug
Leas work. Very nice.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [transaction] splitting ResourceManager interface
Posted by Joerg Heinicke <jo...@gmx.de>.
Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:
> That certainly is post 1.2, right? Maybe even some work for a 2.0
> version?
Yes, definitely after the current release process. We can decide whether it gets
1.3 or 2.0 or what else, when we have the code :)
> Hmmm. Why do you need FileResourceManagers in the fist place? Just to
> synchronize file access? Not quite sure here...
Not that much synchronizing, but more the transactional behaviour. The
FileResourceManager in my use case also takes part in global transactions. You
remember my work on the XA stuff at the beginning?
(OT: Sometimes ago I mentioned that this XAResource implementation might be
donated to Commons Transaction. I got no go from my employer at that time. We
were taken over by another company and our management did not want to decide
about those things. Maybe I should put it back on the table ...)
> 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.
Ok, naming clashes might better be avoided. But from the meaning I chose the
name after comparing with the JTA TransactionManager interface as the
ResourceManager's methods related to transaction handling and the JTA
TransactionManager methods are quite similar. So I don't think there is a
different meaning. And how many ResourceManagers exist in the world? ;)
> One way would be to leave the ResourceManager interface untouched and
> introduce your two new interfaces. FileResourceManager would implement
> all three interfaces.
Yes, of course ... good idea ...
> 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...
I don't want to change that much at the moment. Just splitting the concerns with
care for backward compatibility.
About Java 5: I have never used it yet. Don't know what it can really buy us
though I read much about its nice features.
But let's do one step after another ;)
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [transaction] splitting ResourceManager interface
Posted by Oliver Zeigermann <ol...@gmail.com>.
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 <jo...@gmx.de>:
> 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...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [transaction] splitting ResourceManager interface
Posted by Joerg Heinicke <jo...@gmx.de>.
Hello Oliver,
Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:
> The ResourceManager interface rather is some sort of relict from older times.
> No need to worry much about it except for backward compatibility.
This can be the hardest thing to worry about ;)
> Why change things in the first place? Just because the
> FileResourceManager is huge? That is not a bad thing all by itself.
> Some classed simply get big. Compare it to the String class. It is
> twice as big.
No, hugeness is not something I really worry about. The risk of breaking
anything even by the simplest change is mostly not worth the gain. So I don't
care about size but number of concerns, what's a big difference ... ok, this is
nitpicking :)
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.
Hope this explains it a bit ...
> 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.
> P.S.: I think it might be the time for a 1.2 release. What do you think?
See other thread ...
Jörg
> 2006/7/13, Joerg Heinicke <joerg.heinicke <at> gmx.de>:
> > Hello,
> >
> > the more I work with the FileResourceManager the more I'm convinced that the
> > ResourceManager interface should be splitted into two interfaces: one for
> > handling the locking and transactional stuff (proposal: TransactionManager)
> > and one for actually handling the resources (as is: ResourceManager).
> >
> > One the one hand the only implementation, the FileResourceManager, simply
> > does too much, i.e. too many concerns are handled in it. On the other hand I
> > extend my local version of the FileResourceManager with more and more
> > methods to emulate a file system access (methods from java.io.File
> > actually). In theory I would need to add these methods to ResourceManager
> > interface to be able to work with interfaces, but it would get bigger and
> > bigger.
> >
> > Instead I wonder if a generic ResourceManager interface (in my new sense as
> > described above) is appropriate at all. Probably it would be more
> > appropriate to rename it to FileResourceManager or introduce
> > FileResourceManager interface extending ResourceManager. The splitting of
> > the current ResourceManager interface would allow to reuse the
> > transaction/locking capability with different ResourceManagers (in my new
> > sense).
> >
> > The splitting should be quite easy IMHO. The concerns are quite good
> > separated in the FileResourceManager.
> >
> > WDYT?
> >
> > Regards,
> > Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [transaction] splitting ResourceManager interface
Posted by Oliver Zeigermann <ol...@gmail.com>.
Hi, Jörg!
My first implementation of FileResourceManager really implemented two
interfaces that were close to what you propose. The idea was to have
impementations other than to the file system. The ResourceManager
interface rather is some sort of relict from older times. No need to
worry much about it except for backward compatibility.
Why change things in the first place? Just because the
FileResourceManager is huge? That is not a bad thing all by itself.
Some classed simply get big. Compare it to the String class. It is
twice as big.
Anyway, if you want to introduce something new, got ahead, but be
aware of backward compatibility issues.
Oliver
P.S.: I think it might be the time for a 1.2 release. What do you think?
2006/7/13, Joerg Heinicke <jo...@gmx.de>:
> Hello,
>
> the more I work with the FileResourceManager the more I'm convinced that the
> ResourceManager interface should be splitted into two interfaces: one for
> handling the locking and transactional stuff (proposal: TransactionManager) and
> one for actually handling the resources (as is: ResourceManager).
>
> One the one hand the only implementation, the FileResourceManager, simply does
> too much, i.e. too many concerns are handled in it. On the other hand I extend
> my local version of the FileResourceManager with more and more methods to
> emulate a file system access (methods from java.io.File actually). In theory I
> would need to add these methods to ResourceManager interface to be able to work
> with interfaces, but it would get bigger and bigger.
>
> Instead I wonder if a generic ResourceManager interface (in my new sense as
> described above) is appropriate at all. Probably it would be more appropriate to
> rename it to FileResourceManager or introduce FileResourceManager interface
> extending ResourceManager. The splitting of the current ResourceManager
> interface would allow to reuse the transaction/locking capability with different
> ResourceManagers (in my new sense).
>
> The splitting should be quite easy IMHO. The concerns are quite good separated
> in the FileResourceManager.
>
> WDYT?
>
> Regards,
> Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org