cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Fortress Migration Strategy
Date Thu, 16 Oct 2003 14:24:06 GMT
Stephen McConnell wrote:
> 

> 1. Cocoon defines this as a service (i.e. a SessionThingFactory 
> dependency), or
> 2. Avalon defines a standard "custom" lifestyle policy tag in the 
> avalon-meta
> package (and the coresponding backend)
> 
> Any other solution will result in the specialization of Fortress for 
> Cocoon which will result in the continuation of the division between 
> preventive and dynamic containment semantics (i.e. the Phoenix versus 
> ECM semantic fork). A quick solution is to craft some extra 
> functionality into Fortress to deal with immediate requirements - but 
> the better solution is to take a moment and think the implications - 
> sort out strategy with clean semantics - and do it right. Fortress is 
> positioning as a migration path to Merlin. Merlin is positioning as an 
> step in the delivery of a next generation Avalon containment solution. 
> The final solution has one set of generic semantics that are 
> sufficiently defined to be implementable and supportable at the level of 
> interface specification – i.e. a framework, meta and container spec.

Let's not get bogged down too far with this.  I understand your concerns.
However, they have themselves pretty well embedded with ECM semantics.
The idea here is to dig them out one step at a time.

The core reason for this approach was a performance/resource issue.  With
a pooled component, we run into the problem of having several copies of
this component for the same request for some reason.  In some ways this is
unavoidable.  However the overhead of looking it up and releasing it multiple
times resulted in alot of overhead.

With Fortress, I beleive the performance question is greatly minimized.
The chief question is one of resources.  Cocoon has to deal with a number
of requests simultaneously.  We might not have to deal with the per-request
lifecycle issues any longer.

The big question here is if there are other side affects with them.  For
the short term, I would like to see if we can get away with Fortress pooled
and per-thread components.  If there are side-effects that come from removing
the per-request idiom, then there might be other ways around it that we can
explore that won't affect the core of Avalon interfaces or contracts.  But
let's not get the cart before the horse here.

We can do some performance testing after Cocoon is converted.

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


Mime
View raw message