avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Divergence from Avalon (was Re: [RT] Is Poolable Harmful?)
Date Thu, 10 Jan 2002 17:55:50 GMT
Hi Leo, answer inline:

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Thursday, January 10, 2002 4:58 PM
> 
> ...
> > 
> > Leo Sutic wrote:
> > 
> > That is one implementation.  However, the contract of a ComponentManager
> > is to match a lookup request to a Component--nothing more.
> 
> Yes, but there must be some predictability here. The returned object
> must be castable to the asked-for interface, and there must be some
> standard way of configuring a component manager so that the configurator
> can with reasonable confidence say that "this will map the lookup 
> request X to component Y."
> 
> You may want the CM to be a very general thing, to be able to 
> handle lookups
> of not just components, but of everything under the sun, but the 
> less you specify
> about its behavior the less useful it gets.
> 
> At the moment, the CM does one thing and does it very well - 
> handles *components*.

Now, just tell me how specific (not-do-general) the "component" 
concept is to you?
=;o)


> If you need a general lookup class, try an Object DB.

Overkill, does not do all those nice checkings like the ECM, etc.
=:o)

Ok, I argumented about this one in a previous post.


> > If a Servlet that uses Avalon wants to interpret the Context 
> for the URI,
> > and other properties, it is not up to us to limit that 
> approach.  In fact,
> > just such an approach would be very powerful.
> 
> But how would that be done if not via a ComponentSelector?
>
> ...
>
> Not really - whatever logic you want to use to interpret the Context in
> the CM, I would move to a default ComponentSelector and then use 
> as above.   

I see the ComponentSelector as an "implementation detail". I would 
prefer a more generic way of expressing the "indexing" strategy 
used to map key to component.

  
> > ...
> > 
> > This approach simplifies the use of the Component infrastructure 
> > tremendously as we no
> > longer have to have big complex try/catch/finally methods to 
> > ensure that we release
> > all components even if they are ThreadSafe.
> 
> Then you make the user of a component have to keep track of whether
> a component is thread safe or not, which is bad. Now, I can treat all
> components as being just components, irrespective of whether they are
> pooled or single threaded or threadsafe. While you will save 3-4 lines 
> of code, I think this will result in a massive increase in coupling.
> 
> What if a previously pooled component by some magical way becomes
> thread safe? With your proposal, that would be a backwards-incompatible
> change.

I also do not like this method. Again, it makes it harder to use 3rd
party components, even because of a possible name colision with the
dispose() method.

Besides, as I mentioned before, it is a completelly different contract
and keeping the Component name raises some confusion.


I prefer the way I solved the problem - the "token" way. You just pass
some token that identifies your task and you can release all components
in a single step. This "token" can just be the current thread, like 
this:

  Object myToken = Thread.currentThread();

  try
  {
      MyClass1 cmp1 = (MyClass1)cm.lookup(myToken, "myRole1", "myHint1");
      MyClass2 cmp2 = (MyClass2)cm.lookup(myToken, "myRole2", "myHint2");
      MyClass3 cmp3 = (MyClass3)cm.lookup(myToken, "myRole3", "myHint3");  

      // And now lets do a lot of stuff...

      ...

      // ...a lot of stuff done.
  }
  finally
  {
      cm.releaseAll(myToken);
  }


My mechanism only keeps track of components identified as 
SingleThreaded, which includes the pooled ones, which are 
identified by their factory as I described before in this
thread.

  
> > Also by enforcing the lifestyle of the Components like this, we 
> > encourage threadsafety
> > as a system goal--which does increase the efficiency of using 
> > system resources.
> > 
> > Of course, we could address the whole issue by returning to the 
> > concept that all Components
> > must be ThreadSafe
> 
> No. Then we would end up with all components being factories.

I found it fine all components HAVING fatories, which as I
described before was NOT extra work.

Besides that, how can one make a pooled DB Connection thread safe??

> 
> > , and in the cases of a Transformer that 
> > extends ContentHandler it would
> > have to be changed like this:
> > 
> > interface Transformer
> > {
> >      XMLFilter getFilter(Context context, String source, Parameters);
> > }
> > 
> > That way, the part of the interface that precluded the 
> > Transformer from being ThreadSafe
> > returns a unique instance to be used in the Pipeline.
> > 
> > In the end, this may be the best option in all,
> 
> Not by far.

We will get there.
=:o)


Have fun,
Paulo Gaspar

http://www.krankikom.de
http://www.ruhronline.de
 


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message