geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: [XML Parsing]
Date Fri, 05 Sep 2003 03:28:37 GMT
On Thursday, September 4, 2003, at 10:15 PM, gianny DAMOUR wrote:

> Dain wrote:
>>> It is true that MethodProxy is super fast (I also gave it a try), 
>>> however - I may be wrong here - the number of hits on the Manageable 
>>> Objects will not be significant enought to see a true performance 
>>> improvement.
>> It really depends on how we implement things.  There may be some 
>> services that get hit often (especially if you have a monitoring 
>> application).  Using a MethodProxy is just as easy a using 
>> reflections so I will most likely always use it.
> Thanks for this answer.
> I agree: it depends on how we implement things. For instance, a 
> monitoring application could either poll the Manageable Objects or 
> register an AttributeChangeNotification listener to keep its display 
> updated.
> My believe is that a monitoring application, which uses a polling 
> mechanism, is not implemented correctly expecially if the Manageable 
> Objects emits notifications. The fact that such applications may have 
> an intrusive impact is "acceptable".


> Acutally, my real concern was to have a simple implementation in a 
> first stage and then roll-out an attribute cache, if required. Indeed, 
> AFAIK this cache must be keep in sync. In order to keep this cache in 
> sync, the manageable objects MUST emit attribute change notifications, 
> and the cache needs to listen to them. Even if such an implementation 
> could be trivial, it adds a complexity to the solution.

That is not really how caching works; it is simply timed invalidation.  
When getAttribute is invoked we simply check if the last read is still 
valid.  If it is still valid we return the cached value; otherwise we 
call the getter directly.  It is useful for attributes that never 
change and for attributes where slightly stale data is okay.   For 
everything else you disable caching.

Attribute change notifications will be handled by the GeronimoMBean 
directly.  If the target changes values internally we won't see those 
unless the target sends the notification itself using the 
GeronimoMBeanContext handle, but it will need to distinguish between 
internal changes and changes from the GeronimoMBean or listeners will 
see two change notifications.

All of the code is in, so take a look at it.


  * Dain Sundstrom
  * Partner
  * Core Developers Network

View raw message