Issue 10722: Prevent writing contents of CacheAccess while 'invalid' relations exists (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Revision Severity: Summary: Problem: It is desirable to prevent an application from writing changes that are in itself inconsistent. Changes are inconsistent when for example a NIL pointer for a relation that was modeled as mandatory is still set (in predefined mapping, what would one put into the key values?!) or a relation to an object that is marked to be disposed in the next write operation (setting such relations is allowed, as long as they are reset again when writing the contents.). The latter is to be prevented to ensure receiving application do not get inconsistent data, i.e. a relation to a deleted object which could result in an AlreadyDeleted exception is to be prevented at all costs. To prevent such inconsistencies to be inserted into the system we propose to let the write operation throw an InvalidObjects exception to indicate the application has created an invalid state within the CacheAccess. To determine which objects are invalid an operation should be added to retrieve all invalid objects in the CacheAccess. And each ObjectRoot should have an operation to retrieve the names of the relations which cause the object to be marked as an invalid object. Solution: Add new Exception in the exception list on page 3-18: · InvalidObjects - To be thrown during the write operation of the CacheAccess to indicate invalid objects exist in the CacheAccess. An invalid object is defined as an object which has one or more invalid relation(s). On page 3-48 in section 3.2.1.2 IDL description the exception list should be expanded to include the following definition: exception InvalidObjects {string message;}; Change the description of the write() operation on the CacheAccess on page 3-21, add the following: An InvalidObjects exception is raised if one of the objects contained within the CacheAccess has one or more invalid relation(s) Add the following operation to the CacheAccess class in figure 3-4 on page 3-16: get_invalid_objects() Add the following operation description to the end of the table of the CacheAccess in section 3.1.6.3.3, page 3-21. get_invalid_objects ObjectRoot[] Add the following description for operation get_invalid_objects() right after the description of operation delete_contract · Returns a list of all ObjectRoots which have one or more invalid relation(s). This operation should be used to recover from an InvalidObjects exception thrown by the write() operation. (get_invalid_objects) Add the following operation to the collection class in figure 3-4 on page 3-16 get_invalid_elements() get_element_status() Add the following operations to the ObjectRoot class in figure 3-4 on page 3-16: get_invalid_relations() get_relation_status () Add the following operation description to the end of the table of the Collection entity in section 3.1.6.1.15 on page 3-38 get_invalid_elements <undefined element type>[] get_element_status RelationStatus value <undefined element type> Add the following description for operation 'get_invalid_elements()' right after the description of operation 'values': · Returns all elements which are seen as invalid by the DLRL. An element is invalid when it refers to an object with the write_state OBJECT_DELETED or when the collection is a composition, but the constituent object referred to by the element is also referred by another composition relation or when the relation is an association but the associated object referred to by the element does not correctly point back to the object. (get_invalid_elements) · Returns an enumeration indicating wether the element indicated by the value parameter is valid or invalid (and the exact relation why it is invalid). If the element is not known within the scope of the Collection than a NoSuchElement exception is raised. (get_element_status) Add the following operation description to the end of the table of the ObjectRoot entity in section 3.1.6.3.14 on page 3-34: get_invalid_relations string[] get_relation_status RelationStatus name string Add the following description for operation invalid_relations () right after the description of operation is_modified · Returns a list of relation names which are seen as invalid by the DLRL. A relation is invalid when it refers to an object with the write_state OBJECT_DELETED or when the relation is a NIL pointer but modeled as a mandatory relation (cardinality of 1) or when the relation is a composition, but the constituent object is also referred by another composition relation or when the relation is an association but the associated object does not correctly point back to the object. For relations that are collections the cardinality reason can not result in the relation being seen as invalid. (get_invalid_relations) · Returns an enumeration indicating wether the relation indicated by the name parameter is valid or invalid (and the exact relation why it is invalid). If no relation is known with that name within the scope of the ObjectRoot than a PreconditionNotMet exception is raised. (get_relation_status) On Section 3.2.1.2 IDL description on page 3-47 directly following the ObjectState enum add the following enum: enum RelationStatus{ //The relation has no violations. VALID, //The relation is a NIL pointer but was modeled as a mandatory relation. CARDINALITY_VIOLATION, //The relation points to an object with read_state OBJECT_DELETED or //an object which was already garbage collected. LIVELINESS_VIOLATION, //The related object does not correctly associate itself with the 'owner' object //of this relation. ASSOCIATION_VIOLATION, //The related object is a constituent object in more then one composition relation. COMPOSITION_VIOLATION }; On Section 3.2.1.2 IDL description on page 3-51 regarding valuetype ObjectRoot add the operation description: StringSeq get_invalid_objects(); RelationStatus get_relation_status(in string name) raises (PreconditionNotMet); On Section 3.2.1.2 IDL description on page 3-55 regarding valuetype List add the operation description: LongSeq get_invalid_elements(); RelationStatus get_element_status(in long index) raises (NoSuchElement); On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype StrMap add the operation description: StringSeq get_invalid_elements(); RelationStatus get_element_status(in string key) raises (NoSuchElement); On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype IntMap add the operation description: LongSeq get_invalid_elements(); RelationStatus get_element_status(in long key) raises (NoSuchElement); On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype Set add the operation description: /* To be properly typed in the generated derived classes: * * ObjectRootSeq get_invalid_elements(); * RelationStatus get_element_status(in ObjectRoot value) raises (NoSuchElement); */ On section 3.2.1.2.2 Implied IDL on page 3-62 regarding valuetype FooSet add the operation description: FooSeq get_invalid_elements(); RelationStatus get_element_status(in Foo value) raises (NoSuchElement); In section 3.2.1.2 IDL description on page 3-57 regarding the CacheAccess add the exception InvalidObjects to the raises clause of the write operation. void write() raises (PreconditionNotMet, DCPSError, InvalidObjects, TimeOut); See issues XXX, XXX and XXX for details about the other exceptions and why the readonlymode exception was axed. Resolution: Revised Text: Actions taken: February 13, 2007: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 13 Feb 2007 16:44:20 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10722 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10722 From: "Erik Hendriks" Prevent writing contents of CacheAccess while 'invalid' relations exists Problem: It is desirable to prevent an application from writing changes that are in itself inconsistent. Changes are inconsistent when for example a NIL pointer for a relation that was modeled as mandatory is still set (in predefined mapping, what would one put into the key values?!) or a relation to an object that is marked to be disposed in the next write operation (setting such relations is allowed, as long as they are reset again when writing the contents.). The latter is to be prevented to ensure receiving application do not get inconsistent data, i.e. a relation to a deleted object which could result in an AlreadyDeleted exception is to be prevented at all costs. To prevent such inconsistencies to be inserted into the system we propose to let the write operation throw an InvalidObjects exception to indicate the application has created an invalid state within the CacheAccess. To determine which objects are invalid an operation should be added to retrieve all invalid objects in the CacheAccess. And each ObjectRoot should have an operation to retrieve the names of the relations which cause the object to be marked as an invalid object. Solution: Add new Exception in the exception list on page 3-18: · InvalidObjects - To be thrown during the write operation of the CacheAccess to indicate invalid objects exist in the CacheAccess. An invalid object is defined as an object which has one or more invalid relation(s). On page 3-48 in section 3.2.1.2 IDL description the exception list should be expanded to include the following definition: exception InvalidObjects {string message;}; Change the description of the write() operation on the CacheAccess on page 3-21, add the following: An InvalidObjects exception is raised if one of the objects contained within the CacheAccess has one or more invalid relation(s) Add the following operation to the CacheAccess class in figure 3-4 on page 3-16: get_invalid_objects() Add the following operation description to the end of the table of the CacheAccess in section 3.1.6.3.3, page 3-21. get_invalid_objects ObjectRoot[] Add the following description for operation get_invalid_objects() right after the description of operation delete_contract · Returns a list of all ObjectRoots which have one or more invalid relation(s). This operation should be used to recover from an InvalidObjects exception thrown by the write() operation. (get_invalid_objects) Add the following operation to the collection class in figure 3-4 on page 3-16 get_invalid_elements() get_element_status() Add the following operations to the ObjectRoot class in figure 3-4 on page 3-16: get_invalid_relations() get_relation_status () Add the following operation description to the end of the table of the Collection entity in section 3.1.6.1.15 on page 3-38 get_invalid_elements [] get_element_status RelationStatus value Add the following description for operation 'get_invalid_elements()' right after the description of operation 'values': · Returns all elements which are seen as invalid by the DLRL. An element is invalid when it refers to an object with the write_state OBJECT_DELETED or when the collection is a composition, but the constituent object referred to by the element is also referred by another composition relation or when the relation is an association but the associated object referred to by the element does not correctly point back to the object. (get_invalid_elements) · Returns an enumeration indicating wether the element indicated by the value parameter is valid or invalid (and the exact relation why it is invalid). If the element is not known within the scope of the Collection than a NoSuchElement exception is raised. (get_element_status) Add the following operation description to the end of the table of the ObjectRoot entity in section 3.1.6.3.14 on page 3-34: get_invalid_relations string[] get_relation_status RelationStatus name string Add the following description for operation invalid_relations () right after the description of operation is_modified · Returns a list of relation names which are seen as invalid by the DLRL. A relation is invalid when it refers to an object with the write_state OBJECT_DELETED or when the relation is a NIL pointer but modeled as a mandatory relation (cardinality of 1) or when the relation is a composition, but the constituent object is also referred by another composition relation or when the relation is an association but the associated object does not correctly point back to the object. For relations that are collections the cardinality reason can not result in the relation being seen as invalid. (get_invalid_relations) · Returns an enumeration indicating wether the relation indicated by the name parameter is valid or invalid (and the exact relation why it is invalid). If no relation is known with that name within the scope of the ObjectRoot than a PreconditionNotMet exception is raised. (get_relation_status) On Section 3.2.1.2 IDL description on page 3-47 directly following the ObjectState enum add the following enum: enum RelationStatus{ //The relation has no violations. VALID, //The relation is a NIL pointer but was modeled as a mandatory relation. CARDINALITY_VIOLATION, //The relation points to an object with read_state OBJECT_DELETED or //an object which was already garbage collected. LIVELINESS_VIOLATION, //The related object does not correctly associate itself with the 'owner' object //of this relation. ASSOCIATION_VIOLATION, //The related object is a constituent object in more then one composition relation. COMPOSITION_VIOLATION }; On Section 3.2.1.2 IDL description on page 3-51 regarding valuetype ObjectRoot add the operation description: StringSeq get_invalid_objects(); RelationStatus get_relation_status(in string name) raises (PreconditionNotMet); On Section 3.2.1.2 IDL description on page 3-55 regarding valuetype List add the operation description: LongSeq get_invalid_elements(); RelationStatus get_element_status(in long index) raises (NoSuchElement); On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype StrMap add the operation description: StringSeq get_invalid_elements(); RelationStatus get_element_status(in string key) raises (NoSuchElement); On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype IntMap add the operation description: LongSeq get_invalid_elements(); RelationStatus get_element_status(in long key) raises (NoSuchElement); On Section 3.2.1.2 IDL description on page 3-56 regarding valuetype Set add the operation description: /* To be properly typed in the generated derived classes: * * ObjectRootSeq get_invalid_elements(); * RelationStatus get_element_status(in ObjectRoot value) raises (NoSuchElement); */ On section 3.2.1.2.2 Implied IDL on page 3-62 regarding valuetype FooSet add the operation description: FooSeq get_invalid_elements(); RelationStatus get_element_status(in Foo value) raises (NoSuchElement); In section 3.2.1.2 IDL description on page 3-57 regarding the CacheAccess add the exception InvalidObjects to the raises clause of the write operation. void write() raises (PreconditionNotMet, DCPSError, InvalidObjects, TimeOut); See issues XXX, XXX and XXX for details about the other exceptions and why the readonlymode exception was axed. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org