cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: [Design] ContainerManager is under fire--let's find the best resolution
Date Fri, 07 Jun 2002 15:59:41 GMT
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> 
> > From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
> >
> >
> > And work itself will be done in XMLSource/XMLPipeline/XMLSink. I got
> > that part. Hope performance will not be sacrificed by this move (you
> > will be new()ing this objects all the time)
> 
> Modern JVMs have better GC policies, and is quicker at handling 
> trivial objects.  You can still do Pooling, but it is handled by 
> the GeneratorManager.

Good.


> > > The new way would probably add a GeneratorManager for this 
> > > purpose. However,
> > > the artifact returned is preinitialized with everything it
> > > needs. The
> > > GeneratorManager, TransformerManager, and SerializerManager 
> > > can all take care
> > > of usage semantics if it handles pooled items.
> >
> > How they differ from ComponentSelector?
> 
> 
> More focused management policies, type safety (no more casting), and
> the "setUp()" method becomes the query method.  This allows more
> specific criteria for Generator types.
> 
> Furthermore, a GeneratorManager can declare its own semantics.  If you
> want the release() method there, then there are no issues conflicting
> with overall CM design.

Ok, it means that for Generator I should create GeneratorManager, and
for XXXXX - XXXXXManager.


> > I think discussion here was carried away from topic... Architecture
of
> > future Cocoon should be discussed separately. I was trying only to
> > clarify how container will handle absence of the release() method.
> 
> The GeneratorManager would handle the release() method, or it would
> declare its semantics for use.
> 
> Component use should not be a function of component lookup.

Ok. What then will be contract between component manager and user? When
you call lookup(), what should you expect - Component,
ComponentSelector, ComponentGenerator, Pool, something else?

Or, I always will get XXXXXManager? Then, lifecycle management will be
moved to XXXXXManager, right?


Good thing about ECM is that component writer can easily switch
ThreadSafe -> Poolable and vice versa without breaking any code using
his component. Will this be the case for new CM?


Also, I remembered about component factories (when component is created
on every request and destroyed on release). Will this be supported with
this new release()less design? You can say that these single-use
components are evil (as single-use servlets), but this is the only
choice for some legacy applications/libaries.


<snip/>

> > > A serializer should _*never*_ modify the content of the XML.  It
> > > can only modify the binary stream's representation of it.
> >
> > It does not. I guess you did not understand my thought. Point is:
> > endDocument is no indication to component manager that this
> > component is
> > free.
> 
> Forget GC for now.  Can you see how it can be done with a
> GeneratorManager?

I think yes.

<snip/>

> > Transformers now invoke: Source, LDAP connections, SQL connections,
> > XML:DB collections, files, Loggers... What makes serializer
> > so special?
> > Why code, say, XML->PDF code again and not reuse? Or
> > SAX->XML-in-a-String?
> 
> What about the sitemap handling the separate sinks, you know the
> pipeline multiplexer/demultiplexer concept?

Kind of invented it... WritableSource is the first step towards this.


> > > Ever.  It is the Sitemap's responsibility to manage all
> > > pipelines--whether they have branched or not.  Once all
> > > processing for
> > > a request is done--and the sitemap or at least the Cocoon
container
> > > knows this unequivicably--then it can reclaim the components.
> >
> >     Exactly!
> >
> > Cocoon *container* knows! But this is *not* indicated by some
> > endDocument() on some (intermediate) component in the middle of
> > processing!
> 
> Which was my original point.  The endDocument() was an example of
> another possibility.  IF you want to extend the SAX spec that says
> a contenthandler  is done when endDocument() is called and it
> can free resources, then that's on you.

Aha! So it was an example of possibility of enhancing ContentHandler
contract. Ok. This is no different from Connection.close() - it is
stated in contract that connection is no good after close().


> > But when and how you collect and return to the pool components used
> > during processing? Right now this is done as soon as component is
not
> > needed. If you to do this only once and only after *whole*
> > processing is
> > finished you are bound to hold (critical) resources longer then
> > necessary.
> 
> That is a price of GC systems.  However, you can make critical
resources
> less prone to extended resource holding by providing something akin to
> the DataSourceComponent, even if you make the release() method part of
> the managing component.

So it is still possible with Avalon 5. Good.

<snip/>

> > > > There are situations when transaction takes hours to process
> > > > (I do not mean DB transaction here). How this will happen?
> > >
> > > Wow.  Hours? Then you need to think of a different way of 
> > > handling that
> > > transaction. That is a deeper design issue that needs
> > > serious thought for that application.
> >
> > Simple example: print invoices at the end of the month. You don't
want
> > to hold lots of critical resources during, say, 8 hour process in
> > top-level component which performs this, right?
> 
> Yes, but you wouldn't necessarily have your production (i.e. web)
system
> doing this either. 

We have single J2EE container here for web and back-end...


> It would be an offline process kicked off from the
> commandline
> (chron daemon) or something else along those lines.  It is an
> asynchronous process. 

It is async, it could be kicked off from cron, but it would run in the
container (cause it will use all the application logic - residing in the
container).


> Smarter component design will allow you to avoid necessary
> pooling,
> causing fewer resources to be used, less resource contention, and
> ultimately higher performance.

I agree that no pooling == higher performance. Best performing program
is ThreadSafe block in assembler.

<snip/>

> > J2EE has REQUIRES_NEW transaction management attribute for the EJB
> > method. If you have such methods (is it considered wrong design?),
all
> > required for this method TxResource-s should be looked up,
> > thus you will
> > have more then one instance of a component.
> 
> J2EE also allowed you to declare Servlets as single use (not one
> instance
> per thread or sharing an instance among threads)--does that make it
> correct design?  It was a serious bottleneck allowing a Q&D hack.

Sometimes you have to use some legacy systems, which are not necessarily
written up to high-end Avalon standards... SingleThreaded servlets
should be considered as a way to integrate such things.


> > > BTW, The Fortress
> > > container has a much shorter release() cycle because it handles
> > > the logic asyncronously.  It may take a little longer getting the
> > > instance into the pool, but it doesn't affect the critical path.
> >
> > This will have to be benchmarked then.
> 
> There is a performance benchmark that uses ECM/Fortress in Fortress's
> test code.  It has been compared.

Cool.

Vadim



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message