> From: Berin Loritsch [mailto:[EMAIL PROTECTED]] > > > From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]] > > > > > > 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
