I think there were a lot of discussions over the last years in the Avalon list about a similar topic: making all components thread safe and use a factory approach for poolable components. But unfortunately all these discussions got very confusing for me and I couldn't follow them :) So perhaps this is a topic for Avalon?
Carsten > -----Original Message----- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 10, 2004 11:31 AM > To: [EMAIL PROTECTED] > Subject: [RT] Alternatives to Poolable > > Found a very interesting read at > http://www-106.ibm.com/developerworks/library/j-jtp01274.html? > ca=drs-j0504 > > This articles explains the memory allocation and collection > strategies of modern JVM and show that object recycling and > pooling can cause more harm than good. > > I've always been worried by the fact that most of our > stateful components are Poolable (stateless ones are > ThreadSafe) and not simply SingleThreaded. > > We make them Poolable because their creation cost is high. > But why so? > Because the Avalon framework brings a lot of overhead to > object creation by going through the various lifecycle > interface, and because each of the created instances has to > perform repetitive actions that could be shared between the > various instances. The main cost in this area is parsing the > configuration, which is the same for all instances of a given > component. > > This leads to identifying something I would call "component fields" > which are between static fields (system-wide values for a > class - identical for the various component declarations > using a class) and instance fields (specific to a given instance). > > How can we solve this? I see two solutions: > - define a new lifestyle that would ask the container to hold > those "component fields", and have them computed once at > startup by one instance of the component class. This strategy > is similar to PreparedMatcher. > - avoid stateful component definitions everywhere it is > possible. For example (I already talked about this), the > Transformer interface, instead of being an XMLPipe (and thus > a ContentHandler), could be a factory with a single method > "getContentHandler" method. > > These approaches can allow to remove most of the object pools > that are the most difficult point in tuning Cocoon for performance. > > The first idea complexifies the contract between components > and the framework, which may not be a good idea (see [1] and > [2] for very interesting reads on this subject) whereas the > second approach requires some deep changes to what we have today. > > These are random thoughts, but WDYT? > > Sylvain > > [1] http://lsd.student.utwente.nl/jicarilla/TooMuchMagic > [2] > http://lsd.student.utwente.nl/jicarilla/StoryOfThe6LifecycleMethods > > -- > Sylvain Wallez Anyware Technologies > http://www.apache.org/~sylvain http://www.anyware-tech.com > { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, > Projects } Orixo, the opensource XML business alliance - > http://www.orixo.com > > >
