Definitely a much simpler idea to just build the new stack and replace the
old one atomically than to try and build a database for the MBeans.

Cheers

-----Original Message-----
From: Rickard Öberg
To: [EMAIL PROTECTED]
Sent: 10/2/01 12:33 PM
Subject: Re: [JBoss-dev] JMX service architecture: next gen++

David Jencks wrote:

> I would like this best if the jmx server state were transactional with
> versioning optimistic concurrency control, like the firebird/interbase
db. 
> In this kind of scheme, an invocation to a mbean would get a jmx
> "transactional" view of all the mbeans in the jmx server as of the
start of
> the invocation.  The view of mbeans would be stable until the
invocation
> finishes.  Other concurrent changes to mbean state would use "copy on
> write" semantics and be visible (after they were committed) to jmx
> transactions started after the commit of the jmx modifications.  After
all
> uses of a replaced mbean were complete the (now inacessible) old
version of
> the mbean can be garbage collected.  Presumably one could also set up
> externally controlled jmx transactions so several configuration
changes
> could occur atomically within one transaction. I guess I will have to
read
> more of the mbean spec to see if this is consistent with it ;-)


This is doable, but the overhead of it would be enormous... I think 
sticking with immutable interceptor stacks is good enough to start with
:-)


> Optimistic/versioning or not, I think some kind of jmx transaction to
make
> configuration invisible until it all completes will be necessary to
make on
> the fly reconfiguration plausible and not too disruptive.


Not necessarily. All you need to do is have duplicate MBeans and then 
switch from one set to the other in one atomic operation.

Still, this is really tricky to get right.

> How is this much worse than we have now?  Now we have
standardjboss.xml
> with a list of interceptors: then we will have this configuration in a
> "endpoint" mbean as a list of mbean references, and also mbean
> configuration for each interceptor individually.


You may be right. It could be ok.

/Rickard

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]


_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to