If you use copy on write of the MBeans (and on the list of MBeans - the stack) then you can probably do everything needed. Of course this raises questions about what is the impact of multiple versions of a specific MBean is, but these are supposed to be stateless interceptor-like MBeans right, so it's not like you're making a new connection pool.
I would think a simple copy on write approach would be the quickest to write, but it needs to be wrapped up so the code adding the new MBean doesn't have to remember to do the copy - it just happens. I imagine this is why the model of a database that just does it, is appealing. Cheers -----Original Message----- From: David Jencks To: jboss-dev Sent: 10/2/01 6:38 PM Subject: Fwd: Re: [JBoss-dev] JMX service architecture: next gen++ [[EMAIL PROTECTED]] (Maybe this time I will get this to the list-third try is the charm?) On 2001.10.02 15:07:05 -0400 David Jencks wrote: (forwarding to list, hope this is ok with you) This is exactly what I was thinking, and what the firebird-style versioning does for you. I am not suggesting storing much of anything in a persistent db, I haven't thought about that yet: what I am talking about is how to make the configuration changes transactional/atomic and allow "pre-completion" invocations complete with the old versions, whereas "post completion" invocations use the new versions. I think this is not that hard to do with firebird as a model, maybe adding the version id into the mbean object name. Needs some more thought. Some of this can be taken care of by copy on write invocation lists, but I'm not sure all of it can. Thanks david jencks On 2001.10.02 14:45:05 -0400 Ole Husgaard wrote: > Hi, > > I've been speculating about this in the context of bean > redeployment. > > Just creating a new configuration (or deployment) and atomically > switching over to it is not really enough: Old transactions that > have used the old configuration (or deployment) should continue > to use that, so the old configuration (or deployment) has to be > kept until all transactions that have ever used it have terminated. > > But to avoid service disruption, calls in the context of new > transactions that have not used the old configuration should be > using the new configuration at the same time as some old > transactions still use the old configuration. > > I agree that this can become very hairy. > > > Best Regards, > > Ole Husgaard. > > > David Jencks wrote: > > > > Don't panic marc, even I don't plan to implement this this week ;-) > > > > Here's the context I'm thinking about, and please note IANASA (I am not > a > > system administrator)... but if I were running the jboss cluster at > > Megacorp Conglomerates, I expect my audit trail requirements would > include > > knowing exactly what configuration was used to process each online b2b > soap > > enabled etc purchase order, yet allow on the fly hot updates to avoid > even > > momentary service disruptions. Also, you don't want half-completed > > configuration changes to start getting used - you want them to finish > > first. I'm just saying this point of view on requirements (if they are > > indeed desirable, I don't really know) is satisfied really well by the > > versioning transaction model of firebird/interbase: transactions get > > numbered as they come in, so you can tell from the log what order they > > happened in, and configuration changes are invisible to all > transactions > > (invocations) that start before the configuration change commits, > whereas > > those after the commit use the new configuration. Conceptually this > seems > > cleaner to me than the "valves" you were talking about to stop MIs > during > > reconfiguration. > > > > As Rickard says, this might have a lot of overhead, and at least some > of > > the properties of this system will come from careful use of copy on > write. > > [snip] > > _______________________________________________ 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
