[Broadening this discussion to admin_at_glassfish]
Today, clients like our web-based GUI have a whole page of
attributes. It makes a JMX setAttributes() call to change a group of
Attributes on one MBean. Any program (AppServer) supporting JMX thus
naturally supports a "batch" change to Attributes on any MBean. The
question is open as to whether we want to go beyond what we do today.
All JMX MBeans offer a batch change feature: the setAttributes(...)
call. One or two or N Attributes can all be delivered with a single
call. JMX semantics suggest that a list of successful Attribute
changes be returned, but we can be more strict and choose to succeed
or fail all of them as a group (what we do today in V2 through our
validator code, or at least that's what I understand).
If more than one MBean is involved (not sure there are such cases),
then it is a series of setAttributes() calls, one for each MBean.
Each of those is a distinct and separate operation, unrelated to each
other as far as the server is concerned. This is no different from
any other API which has configuration scattered across multiple
JavaBeans or other objects. JMX in essence goes beyond the default
to at least allow a batch change on one a single object.
In some cases, a series of setAttribute() calls may be made (singular).
Our low-level Config API might allow a “change many then commit”
facility. This needs investigation. But that facility is not easily
exposed in JMX (or any other remote protocol), because it requires a
stateful server, which does not exist today; all management calls are
stateless. All kinds of issues pop up if a remote client can “lock”
the config for the duration of an extended operation.
...
There are use cases that require a bulk set eg setAttributes().
These occur when some values must not conflict or must meet some
range requirements. Consider this case:
Existing values: Min=10, Max=20, Default=15
This sequence will fail on the above values, because Max is < Default
and Default < Min. (This has already been an issue in the V2 GUI
which required recoding to specify the values in a non-conflicting
order).
setAttribute( {"Max",10} );
setAttribute( {"Default",5} );
setAttribute( {"Min",3} );
Any of the sequences below can succeed because the values are self-
consistent, and the invocation includes them all as a "batch":
setAttributes( {"Min",3}, {"Max",10}, {"Default,5"} )
setAttributes( {"Max",10}, {"Default,5"}, {"Min",3} )
setAttributes( {"Max",10}, {"Min",3}, {"Default,5"} )
etc
Lloyd
On Oct 18, 2007, at 8:49 PM, Bill Shannon wrote:
> Lloyd L Chambers wrote:
>> Jerome,
>> Possible config solutions range from a fully transactional API
>> that allows rollbacks of arbitrary numbers of changes across
>> arbitrary numbers of config elements/MBeans to one that allows
>> changes to only a single value at a time. I don't propose either
>> of those approaches.
>> I think the *happy medium* is one that allows N attributes to be
>> changed as a group within a single config element/MBean,
>> succeeding or failing as a group. I think that we actually have
>> this capability internally today, but it is not necessarily
>> exploited by our tools (at least not in many cases).
>
> What are the use cases for why this is important? It certainly adds
> complexity, although not as much as the fully transactional API.
>
>> Allowing arbitrary changes across an entire module config
>> hierarchy is complicated, but perhaps even more so for the module
>> writer, who might then have to accommodate wholesale changes to
>> multiple running threads/services of that module. So I don't
>> think that is a worthwhile goal, though we shouldn't preclude
>> being able to do it in the future.
>> But this area is definitely worthy of discussion. Perhaps our
>> sights do need to be significantly higher than in V2. I'm not sure
>> of the use cases though.
>
> Use cases are important here.
>
> Do you know if any other app servers support anything more than
> changing
> a single value at a time?
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc