[Forwarding to the list. %#�%& missing Reply-To: header] -------- Original Message -------- Subject: Re: [JBoss-dev] JMX service architecture: next gen++ [davidje [EMAIL PROTECTED]] Date: Wed, 03 Oct 2001 22:15:28 +0200 From: Ole Husgaard <[EMAIL PROTECTED]> Organization: Sparre Software To: David Jencks <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Hi, Having some VM-local centralized service that gives serial numbers to transactions would be possible. But how about routing MBean invocations to the right MBean version? For this to work we would need another layer for doing the invocation routing. With this layer we could get around the garbage collection problem, if it is notified of the termination of jmx transactions. The routing layer would have to remember old transactions to know which version to route the invocation to. If the transaction has not been seen by the routing layer, it just routes to the most recent version and remembers that this tx should use this version. When the routing layer is notified that a transaction has ended, it forgets its association between the mbean version and the transaction. If this means that no more transactions are associated to an old version mbean, it can garbage collect the old mbean. But still, a bit too hairy imho. Best Regards, Ole Husgaard. David Jencks wrote: > > 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 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
