Issue 10771: Give each CacheAccess its own Publisher and DataWriters (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Revision Severity: Summary: Problem: If one of the purposes of the CacheAccess is to separate sets of objects that are being manipulated by different threads from eachother, then it makes sense to also give them a separate Publisher. Otherwise different threads might try to write different coherent sets of information using the same DataWriters at the same time, thus mixing up two separate coherent sets as one big chunk. Also with respect to tailoring QoS settings the modifying threads might influence each-other. Solution: Giving each CacheAccess its own Publisher and DataWriters allows you to completely separate each thread of modification. Coherent Sets that are being written always have exactly the right coherence scope, and it is possible to have different CacheAccess objects for different purposes: for example one CacheAccess to write the objects reliably, another one to send them with best-effort. Creating a CacheAccess then implicitly creates a Publisher and all the required DataWriters for all ObjectHomes attached to the main Cache, using the same QoS settings as the writers already attached to the main Cache. To allow the user of a CacheAccess to tailor these QoS-settings, all these DCPS entities should be created in a disabled state. That means that the CacheAccess would require a new operation called 'enable' to enable them all. Also it means that since the CacheAccess will have its own Publisher, the 'the_publisher' attribute can be moved from the Cache to the CacheBase interface. Question is why a Cache still requires a Publisher if you are only allowed to write information from a CacheAccess. We see no reason why a Cache could not be used to write information as well: there are sufficient mechanisms available in DLRL to prevent manual modifications being overwritten by automatic updates: one could disable the automatic updates for this purpose, or one could do the modification during a listener callback, thus blocking new updates from being applied. Also for a WriteOnly application it makes sense to have a writeable Cache. We therefore also propose to move the write operation from the CacheAccess to the CacheBase class and to change the CacheAccess parameter in the create_object and create_unregistsred_object operations into a CacheBase operation. TBD. Resolution: Revised Text: Actions taken: February 15, 2007: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 15 Feb 2007 13:43:20 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10771 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10771 From: "Erik Hendriks" Give each CacheAccess its own Publisher and DataWriters Problem: If one of the purposes of the CacheAccess is to separate sets of objects that are being manipulated by different threads from eachother, then it makes sense to also give them a separate Publisher. Otherwise different threads might try to write different coherent sets of information using the same DataWriters at the same time, thus mixing up two separate coherent sets as one big chunk. Also with respect to tailoring QoS settings the modifying threads might influence each-other. Solution: Giving each CacheAccess its own Publisher and DataWriters allows you to completely separate each thread of modification. Coherent Sets that are being written always have exactly the right coherence scope, and it is possible to have different CacheAccess objects for different purposes: for example one CacheAccess to write the objects reliably, another one to send them with best-effort. Creating a CacheAccess then implicitly creates a Publisher and all the required DataWriters for all ObjectHomes attached to the main Cache, using the same QoS settings as the writers already attached to the main Cache. To allow the user of a CacheAccess to tailor these QoS-settings, all these DCPS entities should be created in a disabled state. That means that the CacheAccess would require a new operation called 'enable' to enable them all. Also it means that since the CacheAccess will have its own Publisher, the 'the_publisher' attribute can be moved from the Cache to the CacheBase interface. Question is why a Cache still requires a Publisher if you are only allowed to write information from a CacheAccess. We see no reason why a Cache could not be used to write information as well: there are sufficient mechanisms available in DLRL to prevent manual modifications being overwritten by automatic updates: one could disable the automatic updates for this purpose, or one could do the modification during a listener callback, thus blocking new updates from being applied. Also for a WriteOnly application it makes sense to have a writeable Cache. We therefore also propose to move the write operation from the CacheAccess to the CacheBase class and to change the CacheAccess parameter in the create_object and create_unregistsred_object operations into a CacheBase operation. TBD. 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