Issue 3920: FT-FTF Issue: Request more powerful property management (ft-ftf) Source: AT&T (Mr. Robert E. Gruber, ) Nature: Uncategorized Issue Severity: Summary: There are 3 problems w.r.t. property management which I will list together since a solution could/should address all of them. I will send a proposed solution in another message. --------------------------------------------------------------- ** Problem A ** For sequence-valued properties, there should be a way to add or remove one or more elements from a sequence value without having to resort to using more than one method call. Notes: Currently, one has to 'get' the current sequence value, modify it, and then 'set' the sequence value. This results in a nasty race condition: it is not safe to have independent threads of control doing get-set combinations. A simple solution is to have new methods for element update. A complex solution is to allow any number of updates, including property set, element addition, element removal, for default and type and dynamic, all to be grouped and sent to the manager in one property_update request. For example, one might want to group the removal of a property P from type T and the addition of property P as a default property. --------------------------------------------------------------- ** Problem B ** The property management interface has insufficient power. Notes: One can query or update over a single type or a single object group, but not over a set of types or a set of object groups. Further, one cannot: * get a list of types that have + at least 1 property defined; + specific propert[y|ies] defined; + at least 1 factory at specific location[s]; [ or modify properties for the specified types ] * get a list of existing object groups that have + specific propert[y|ies] defined; + specific type[s]; + an active replica at specific location[s]; [ or modify properties for the specified object groups ] * get a list of active replicas that have + specific type[s]; + specific location[s]; [ or modify properties for the specified replicas ] * get a list of locations that have + at least 1 property defined; + specific propert[y|ies] defined; + at least 1 active replica; + an active replica for specific object group[s]; + an active replica of specific type[s]; [ or modify properties for the specified locations] * other query/update cases that should be supported? --------------------------------------------------------------- ** Problem C ** The property management interface does not sufficiently distinguish between high-level FT QoS properties used to manage entire object groups and low-level object construction properties used to select factories and create individual replicas. Notes: High-level QoS properties change infrequently, and never differ across replicas. Low-level construction properties change more frequently as factories are created/destroyed/lost, and they do differ across locations/replicas (different factories, different criteria). In each case, one must distinguish between properties for an existing object group and properties to be used for future object groups. Even for replica construction properties, one should be able to assign a different set of locations/factories to be used for new replica creation for existing object group[s] and for future object groups. Currently, low-level properties are buried in a single value that is stored with a single property (FactoryInfos), either for a specific type or for a specific object group. This makes it very hard to do lookup or modification of these properties by location or by the pair type x location or object group x location. To replace an Info for a single location one must replace the entire Infos sequence. Even with the ability to add/remove a member of a sequence, to replace either the factory or the criteria within a given Info one would have to remove the current Info and replace it with a new Info, where the Info would need to contain a copy of the part(s) that are not to be modified together with the modified part. BTW I am leaning towards splitting the PropertyManager into a GroupQoSManager and a FactoryManager, but other approaches are possible. One argument for the split is that it seems to make sense for a FactoryManager to monitor the liveness of registered factories and to provide logic for selecting an appropriate factory and associated criteria for construction of a new replica for a given group or type. In contrast, it does not make sense for a generic property manager to do monitoring (or to know anything about the values stored in properties). Resolution: Revised Text: Actions taken: September 28, 2000: received issue Discussion: This issue was determined to be out-of-scope of the Fault Tolerant CORBA Finalization Task Force. End of Annotations:===== From: "Robert E. Gruber" To: , , "Juergen Boldt" Cc: "Robert E. Gruber" Subject: FT-FTF Issue: Request more powerful property management Date: Thu, 28 Sep 2000 17:30:18 -0400 Message-ID: <001401c02993$4c7a03d0$c216cf87@pong.research.att.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: _HWd9mm&e9?E9!!pgbd9 An FT-FTF (Fault Tolerance Finalization Task Force) Issue: There are 3 problems w.r.t. property management which I will list together since a solution could/should address all of them. I will send a proposed solution in another message. --------------------------------------------------------------- ** Problem A ** For sequence-valued properties, there should be a way to add or remove one or more elements from a sequence value without having to resort to using more than one method call. Notes: Currently, one has to 'get' the current sequence value, modify it, and then 'set' the sequence value. This results in a nasty race condition: it is not safe to have independent threads of control doing get-set combinations. A simple solution is to have new methods for element update. A complex solution is to allow any number of updates, including property set, element addition, element removal, for default and type and dynamic, all to be grouped and sent to the manager in one property_update request. For example, one might want to group the removal of a property P from type T and the addition of property P as a default property. --------------------------------------------------------------- ** Problem B ** The property management interface has insufficient power. Notes: One can query or update over a single type or a single object group, but not over a set of types or a set of object groups. Further, one cannot: * get a list of types that have + at least 1 property defined; + specific propert[y|ies] defined; + at least 1 factory at specific location[s]; [ or modify properties for the specified types ] * get a list of existing object groups that have + specific propert[y|ies] defined; + specific type[s]; + an active replica at specific location[s]; [ or modify properties for the specified object groups ] * get a list of active replicas that have + specific type[s]; + specific location[s]; [ or modify properties for the specified replicas ] * get a list of locations that have + at least 1 property defined; + specific propert[y|ies] defined; + at least 1 active replica; + an active replica for specific object group[s]; + an active replica of specific type[s]; [ or modify properties for the specified locations] * other query/update cases that should be supported? --------------------------------------------------------------- ** Problem C ** The property management interface does not sufficiently distinguish between high-level FT QoS properties used to manage entire object groups and low-level object construction properties used to select factories and create individual replicas. Notes: High-level QoS properties change infrequently, and never differ across replicas. Low-level construction properties change more frequently as factories are created/destroyed/lost, and they do differ across locations/replicas (different factories, different criteria). In each case, one must distinguish between properties for an existing object group and properties to be used for future object groups. Even for replica construction properties, one should be able to assign a different set of locations/factories to be used for new replica creation for existing object group[s] and for future object groups. Currently, low-level properties are buried in a single value that is stored with a single property (FactoryInfos), either for a specific type or for a specific object group. This makes it very hard to do lookup or modification of these properties by location or by the pair type x location or object group x location. To replace an Info for a single location one must replace the entire Infos sequence. Even with the ability to add/remove a member of a sequence, to replace either the factory or the criteria within a given Info one would have to remove the current Info and replace it with a new Info, where the Info would need to contain a copy of the part(s) that are not to be modified together with the modified part. BTW I am leaning towards splitting the PropertyManager into a GroupQoSManager and a FactoryManager, but other approaches are possible. One argument for the split is that it seems to make sense for a FactoryManager to monitor the liveness of registered factories and to provide logic for selecting an appropriate factory and associated criteria for construction of a new replica for a given group or type. In contrast, it does not make sense for a generic property manager to do monitoring (or to know anything about the values stored in properties).