The other reason I like the database approach (aside from liking its elegance) is that it provides a way to tell when you can throw out the old version of the mbeans: when all invocations [jmx transactions] numbered less than the transaction active when the change committed are complete. Without something like this I'm not sure how to tell when its ok to deregister the old set of mbeans: they're in the mbean server, so they won't just be garbage collected when all the references are gone. Maybe reference counting... but this may be hard to get right.
david jencks On 2001.10.02 21:26:49 -0400 Jay Walters wrote: > 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 > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
