beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eddie O'Neil" <ekon...@gmail.com>
Subject controls core performance issue
Date Tue, 25 Apr 2006 15:29:23 GMT
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

Mime
View raw message