Maintaining Consistency

All relation service operations that set the role of a relation always verify that the role value fulfills its definition in the relation type. An incorrect MBean type, the wrong cardinality of the role, or an unknown role name will prevent that role from being modified, guaranteeing that the relation always fulfills it relation type.

As we shall see in "Objects Representing Relations", relations and relation types can also be objects that are external to the relation service. In this case, they are responsible for maintaining their own role-consistency. The relation service MBean exposes methods to assist these object is verifying that their roles conform to their defined relation type. In all cases of an external implementation of a relation, the object designer is responsible for ensuring its coherence.

Removing a relation type can cause existing relations to no longer have a defining type. The policy of the removeRelationType operation is to assume that the caller is aware of existing relations of the given type. Instead of forbidding the operation, this method removes the relations that were defined by the given type. It is the designer's responsibility to first call the findRelationsOfType operation to determine if any existing relations will be affected.

MBeans participating in a relation may be removed from the MBean server by some other management operation, thereby modifying the cardinality of a role where they were referenced. In order to maintain the consistency in this case, the relation service must remove all relations in which a role no longer has the cardinality defined in it relation type. The process of determining invalid relations and removing them is called a purge.

The relation service listens for deregistration notifications of the MBean server delegate, and will need to purge its MBeans whenever one is received. It must determine if the removed MBean was involved in any relations, and if so, whether its removal violates the cardinality of each role where it appears. The relation service exposes the boolean PurgeFlag attribute which the programmer must set to determines whether purges are done automatically or not.

When the purge flag is true, the relation service will purge its data immediately after every deregistration notification. However, the purge operation can be resource intensive for large sets of relation data. In that case the managing application may set the purge flag to false and only call the purgeRelations operation to purge the data when needed.

For example, if there are many MBean deregistrations and few relation operations, it may make sense to only purge the relation service manually before each operation. Or the automatic purge flag may be temporarily set to false while executing time-critical operations that need to remove MBeans, but that won't access the relation service.

There are two possible consequences of an unpurged relation service. Roles in a relation may reference object names which no longer have an associated MBean. Or worse, the object name may have been reassigned to another MBean, leading to a totally incoherent state. The designer of the management solution is responsible for setting the purge policy so that operations will always access consistent relation values.