Jerome,
In essence both things are happening today in V2:
- changes to Attributes issue individual
AttributeChangeNotifications, one for each changed Attribute. This
is the JMX model, conforming to expectations is important, perhaps
not ideal for our specific use cases, but it is what it is.
- Internally (ConfigInterceptor), a batch change invoked by
setAttributes(...) causes a batch change event to be dispatched,
though this seems to apply only to remote servers.
I don't understand the latter very well; it needs research.
Lloyd
On Oct 19, 2007, at 9:37 AM, Jerome Dochez wrote:
>> Jerome,
>>
>> Today's V2 configuration works to my satisfaction, and I’m not
>> aware of any complaints in regards to changing multiple areas of
>> configuration.
>>
>> In V2, changing configuration across multiple distinct
>> configuration objects ( eg MBeans corresponding to domain.xml
>> elements) does indeed cause a reconfigure even for each affected
>> object.
>>
>> I don't see how the same behavior in V3 would suddenly become an
>> issue.
>
> probably not an issue but if we could generalize the concept of
> batching config changes and then streamline the notification
> process once the batch is finished (without necessarily entering
> the transactional complexity), it might be worth investigating.
>
> It may be ok in v2 that we can get several events for each affected
> object, and we can continue like that worse case, however it would
> be safer as a client code to register interest in a group of object
> and only get notified of changes once that group has finished
> changing.
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc