All-- I've been profiling some of the code that Controls Core uses from the Java class library -- specifically the implementation classes for the BeanContext, BeanContextServices, and BeanContextChild APIs. As it turns out, these classes use a static, final, VM-wide lock:
java.beans.beancontext.BeanContext.globalHierarchyLock that is used to serialize changes to a BeanContext bean hierarchy and service requests (as per its Javadoc). These JDK classes appear to have been written assuming that a bean hierarchy is VM-wide or is at rooted in a shared ancestor in the VM. This is very different from how hierarchies of bean contexts are maintained in enterprise applications where they may be scoped to a page flow, session, application, or container. In the case of NetUI, for example, there is a hierarchy of these beans for every Page Flow. Having these hierarchies share a lock with every other page flow for every user in every web application can cause obvious performance problems. Thus, I'd suggest that we start down the path of providing an implementation of the BeanContext / BeanContextServices / BeanContextChild APIs in order to make the locking patterns required in these classes more granular. For how we tend to use these classes in NetUI and in the ControlFilter (web tier use cases), the ControlBeanContext / ControlContainerContext / ServletBeanContext objects are either soped to a single request or protected by a larger framework and thus single threaded. So, let's build something that reflects this by being single threaded, *fast*, and by making control instantiation very inexpensive. I'm going to look at two options for the existing CBC / CCC / SBC objects: 1) changing the CBC object to delegate to an implementation of the BeanContextServices interface(s) 2) forking these classes and then adding implementations of the interfaces in the java.beans.beancontext package Other thoughts / suggestions welcome. :) Eddie
