commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <>
Subject [transaction] splitting ResourceManager interface
Date Thu, 13 Jul 2006 15:56:47 GMT

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 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.



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

View raw message