geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeremy Boynes" <>
Subject RE: [Deployment] IM #2 Summary for Directory Issue
Date Sat, 04 Oct 2003 09:14:42 GMT
> From: gianny DAMOUR [] 
> Sent: Saturday, October 04, 2003 1:54 AM
> From: "Jeremy Boynes" <>
> Date: Sat, 4 Oct 2003 00:50:19 -0700
> >MBean persistence is used to store the configuration of each 
> MBean (the 
> >values of persistent attributes). This is used to reload the 
> MBeans on 
> >restart. The JSR77 state is not a persistent attribute, so 
> all MBeans 
> >come back in the STOPPED state.
> I see. So the "Persistence Service" snapshots the persistent 
> attribute of an 
> MBean. And the "Service Controler" snapshots the transient 
> attributes, which 
> are specific to the MBean state?
> What I had in mind was to add a persistent attribute to 
> AbstractManagedObject abstracting the target state to reach 
> when the server 
> is restarted. This persistent attribute mirrors the transient state 
> attribute and is persisted based on the installed persistence 
> policy (which 
> could be checkpoint, on attribute change et cetera). The 
> mirroring of the 
> transient state and the target state is broken when a request 
> to shutdown 
> the server is received.

This is why I believe the two need to be separate. The service
controller manages the global state of the server and would be managing
a controlled shutdown; so it can save the target configuration rather
than having to have separate target and actual state values in each
MBean. It also means that all the state can be dumped in one go, rather
than having to persist each MBean individually (which could involve
significantly more data).

> When a ManagedObject is restored, one uses this target state 
> to trigger the 
> relevant operation. One drawback I see in defining two 
> services is that we 
> will end up with two locations to be merged when the server 
> is re-started. 
> Moreover, it allows to share the persistence policy between these two 
> services.

I don't get the two locations bit - I would say there are N+1 persistent
datasets (persistent attributes from N MBeans + 1 target global state
definition (which may be the persistent state of the ServiceController
but that is impl detail)).

> >Given child objects can be stopped, I doubt startRecursive 
> is the way 
> >to go - instead, the controller will need to start each one 
> >individually (and in the correct order).
> startRecursive is not the way to go to restore the identical 
> state. However 
> it will be the more simple to implement.
> Indeed, as you have underlined the controller will need to 
> start in the 
> right order the services. To start in the right order these 
> services, this 
> controller will need to re-implement a significant part of the 
> DependencyService. I agree that the canStart method is a good 
> template to 
> implement such a feature. This is an academic exercice and 
> also quite time 
> consuming.

I have a feeling that the service controller and the dependency service
will be very closely coupled anyway, but that's Dain's problem :-)


View raw message