Aaron Mulder wrote:
> Second, I don't think the "listener" approach to JMX MBean
> ordering will work. Consider that the auto-deployer must deploy after
> *all* databases have started. If it just listens for the database pool
> bean (assuming it can listen on a class rather than instance, so it won't
> have to know *which* pools are there), it may load after one of 10
> databases, which would still cause problems. If we load all the instances
> for a class at once (all pools, etc.) and it waits for that to complete,
> it will never start if there are no pools. There may - may - be some way
> around this if we let each MBean look at the entire list of MBeans before
> it decides which ones to listen for, but this is getting pretty nasty...
> I think it would be simpler for each MBean to list all the MBean
> classes it depends on, and then load all the instances of those (where
> available) first.
First of all, I still think that this stuff should be completely
separate from each MBean. I.e. an MBean would not "list" anything
explicitly, other perhaps in documentation. This will make things a lot
more flexible.
Second, this is simply solved by introducing aggregate MBeans. For
example (all names below are fictious. change where needed):
Add a dummy MBean called "DataSources". Add relationships so that
"DataSources" requires "HypersonicDataSource" and "InstantDBDataSource".
This means that "DataSources" will not be considered started before the
two real datasources have been started. So, now the AutoDeployer can
rely on "DataSources" instead of "HypersonicDataSource". Tada. Solved.
Now, in a simpler setup you would not use the aggregate, and let the
AutoDeployer require, for example, "HypersonicDatabase" directly. Since
relationships should be external to all MBeans this kind of rewiring
would be trivial to do.
Makes sense? The only trouble with this is that we need *SYNCHRONOUS*
message notification for the "stopping" to work properly. Why? Because
the stop code will look something like this:
setState("Stopping");
doStopCode();
setState("Stopped");
--
setState() will trigger message notifications. If this method doesn't
wait until all listeners have been notified they will not have time to
do graceful shutdowns, since doStopCode() will have executed long before
they get the notification....
How to solve?
/Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com
