Hey, While we're on the topic of challenging design decisions, here's another key design decision: currently the concern chains for a method are pooled, and looked up per-invocation. At lookup time the chain is assigned a particular composite instance and mixin, and the call is then proceeded.
The rationale for this is that it would be too expensive to instantiate concern chains per method per composite. The number of concern instances would simply explode. The drawback is obviously the overhead of having to do the pool management and assignment of proxy/mixin on each invocation. Performance vs memory. Since modern VM's are quite good at memory management, and it is reasonably inexpensive to create objects these days, we might want to reconsider this. Especially considering that we know the different types of composites and their different characteristics. For ServiceComposites, where there is only one instance of each type, it is a no-brainer that the concern-chains should in fact be instantiated and kept around for each method per composite instance. There's only going to be one instance of each anyway! This will completely take away the synchronization hit of managing the pool. For EntityComposites, if there is one concern-chain per method per instance there's going to be lots of them. However, one question is how many concerns there are going to be anyway (e.g. most middleware-concerns are on ServiceComposites, not Entities), in a typical case. We also have to remember that Entities are reasonably short-lived, since when the UoW finishes, the Entity goes away and the concerns for it can be GC'ed. Also, if the concern chains are lazy-created, then in a typical usecase it will probably not exercise that many methods in an Entity (methods such as displayName() and identity() will be, but they are Properties and hence have no concerns in the first place!). There's also the option of pooling concern-chains and assigning them to entity instances, and when the UoW completes, the concern-chains are returned to the pool. This way there will be a synchronization hit on the first method call, but after that there is no synchronization at all, and there will also be no GC at all. I think these are the two most important cases to consider. It is perfectly possible to use different strategies for the different cases as well, so keep that in mind. Thoughts on this? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
