Issue 10720: Relationships to objects that have been deleted are not allowed. (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Revision Severity: Summary: Problem: It is possible for situations to arise where an ObjectRoot has a relation to an ObjectRoot which has already been deleted. Imagine we have a relationship between class Foo and Class Bar. In update round 1 we receive both Foo and Bar and create the relationship from Foo to Bar. In update round 2 the Bar object is disposed and thus the read_state is changed to DELETED, at the end of the update round the Bar object is actually deleted, accessing it from that moment on will raise the AlreadyDeleted exception. In this update round the relationship from Foo to Bar has not been reset (this is not unlikely in hybrid (DCPS and DLRL mixed) systems, or even DLRL only systems (topic samples are lost for example). If we try to navigate from Foo to the Bar object after update round 2, then we will get that Bar object, however accessing any operation gives us the (runtime) exception AlreadyDeleted. Because the above example deals with an error situation (The Foo object should have been updated in update round 2 and the relation to object Bar should have been reset, or the sample doing that shouldn't have been lost) we propose to clarify in the specification that it is NOT allowed to have a relationship to an object with the object state DELETED at the time of a refresh. Such relations should transparently be reset by the DLRL to a NotFound exception and the Foo object in the example should be marked as MODIFIED during the update round the deletion of the related object is detected, a call to the is_xxx_modified operation of the Foo object regarding relation Bar should return true. This also ensures that an application can NEVER get an AlreadyDeleted exception unless the application has specifically done something wrong (like maintain a reference to the Bar object in it's own application code and ignored the deletion event). Not allowing relationships to objects that are deleted ensures the same behavior is found for all situation involving relations, which is convinient for the application as it doesn't need to take exceptional situation into account but can be assured the middleware resolves such situations in a uniform manner. Foo is received but no Bar is available results in NotFound. Foo is received, Bar is received as disposed results in NotFound. Foo is received, Bar is received, Bar is then disposed results in NotFound. Solution: Explain the above behavior in the specification. 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:36:43 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10720 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10720 From: "Erik Hendriks" Relationships to objects that have been deleted are not allowed. Problem: It is possible for situations to arise where an ObjectRoot has a relation to an ObjectRoot which has already been deleted. Imagine we have a relationship between class Foo and Class Bar. In update round 1 we receive both Foo and Bar and create the relationship from Foo to Bar. In update round 2 the Bar object is disposed and thus the read_state is changed to DELETED, at the end of the update round the Bar object is actually deleted, accessing it from that moment on will raise the AlreadyDeleted exception. In this update round the relationship from Foo to Bar has not been reset (this is not unlikely in hybrid (DCPS and DLRL mixed) systems, or even DLRL only systems (topic samples are lost for example). If we try to navigate from Foo to the Bar object after update round 2, then we will get that Bar object, however accessing any operation gives us the (runtime) exception AlreadyDeleted. Because the above example deals with an error situation (The Foo object should have been updated in update round 2 and the relation to object Bar should have been reset, or the sample doing that shouldn't have been lost) we propose to clarify in the specification that it is NOT allowed to have a relationship to an object with the object state DELETED at the time of a refresh. Such relations should transparently be reset by the DLRL to a NotFound exception and the Foo object in the example should be marked as MODIFIED during the update round the deletion of the related object is detected, a call to the is_xxx_modified operation of the Foo object regarding relation Bar should return true. This also ensures that an application can NEVER get an AlreadyDeleted exception unless the application has specifically done something wrong (like maintain a reference to the Bar object in it's own application code and ignored the deletion event). Not allowing relationships to objects that are deleted ensures the same behavior is found for all situation involving relations, which is convinient for the application as it doesn't need to take exceptional situation into account but can be assured the middleware resolves such situations in a uniform manner. Foo is received but no Bar is available results in NotFound. Foo is received, Bar is received as disposed results in NotFound. Foo is received, Bar is received, Bar is then disposed results in NotFound. Solution: Explain the above behavior in the specification. 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