> I don't think that ;) But I have used Stoppable throughout my code fairly
> regularly. As startable/stoppable can be called multiple times in
> lifecycle
Ooh. Is that true? Why? It seems to me that any place where you do this
it is better to use suspend/resume instead.
> there are many cases where I will stop something and then start it up
> again. The typical use case of stop involves clearing out caches but my
> start methods would always be empty. I am not sold on it - it is
> just going
> to be an absolute PITA for me to use because I have to change massive
> amounts of code to add in blank methods ;) (And I can't automate
> it safely).
Actually, doing it completely correctly probably means you'll have to
do even more refactoring to make use of Commands and where those are
not neccessary suspend() and resume()...
motivation:
-----------
start() is the parallel method for the one in Thread. As such, it is there
to call run() (this is not how it is/should be used in practice but
is what it indicates). run() itself should only be called once in the
lifetime of a thread/component, while a wait()/suspend() should be called
on it before clearing the cache and a notify()/resume() after that
to continue the work.
I actually believe that the best setup is to have a cache as a separate
thread, and a cachemanager as another separate (daemon) thread, both
living within a component. To clear the cache, the component should call
a method on the manager, without having to stop() itself. If data needs
to be synchronized, well, then it should be synchronized.
In other words, your current setup is probably not optimal (not flawed
but not the best one either); Avalon should promote and enforce the
best setup.
regards,
LSD
<java:sig>
About LSD = new PersonalInfo();
LSD.name("Leo Simons");
LSD.email("[EMAIL PROTECTED]");
LSD.URL( [
http://www.leosimons.com, // personal website
http://www.atfantasy.com, // fantasy RPG portal
http://www.the-sign.nl // web-design company
] );
LSD.quote("Buh!");
email.setSig((String)LSD);
</java:sig>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
