Issue 10749: Various typos in section 3.1.6.3.4, Cache (data-distribution-rtf)
Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com)
Nature: Uncategorized Issue
Severity: 
Summary: Problem (1/5):
Section 3.1.6.3.4 on the table on page 3-22 errornously states the operations load(), lock() and unlock(), which no longer exist since the previous specification update. They have been removed from the idl as well and figure 3-4, but not here.

Solution (1/5):
Remove load(), lock() and unlock() operations from the table on page 3-22

Problem (2/5):
Section 3.1.6.3.4 on page 3-24 still contains various descriptions about operations that no longer exist, namely load, deref, lock, unlock. All these operations were removed in the previous spec revision.

Solution (2/5):
Remove the following texts:
o explicitly request taking into account the waiting incoming updates (load). In case
updates_enabled is TRUE, the load operation does nothing because the updates are
taken into account on the fly; in case updates_enabled is FALSE, the load operation
'takes' all the waiting incoming updates and applies them in the Cache. The load
operation does not trigger any listener (while automatic taking into account of the
updates does - see Section 3.1.6.4, "Listeners Activation," on page 3-41 for more
details on listener activation) and may therefore be useful in particular for global
initialization of the Cache.
o transform an ObjectReference to the corresponding ObjectRoot. This operation can
return the already instantiated ObjectRoot or create one if not already done. These
ObjectRoot are not modifiable (modifications are only allowed on cloned objects
attached to a CacheAccess in write mode).
o lock the Cache with respect to all other modifications, either from the infrastructure
or from other application threads. This operation ensures that several operations can
be performed on the same Cache state (i.e., cloning of several objects in a
CacheAccess). This operation blocks until the Cache can be allocated to the calling
thread and the waiting time is limited by a time-out (to_in_milliseconds). In case
the time-out expired before the lock can be granted, an exception (ExpiredTimeOut)
is raised.
o unlock the Cache.

Problem (3/5):
In section 3.1.6.3.4 on page 3-24 in the middle of the page an indent is missing for the following text. And the paragraph is also ended with a ':', which should be a '.'. In the middle of the text, behind the first bold, italic word Cache it also has a ':', which should be a ';'

Solution (3/5):
Replace:
The purpose of the CacheAccess must be compatible with the usage mode of the Cache:
only a Cache that is write-enabled can create a CacheAccess that allows writing.
Violating this rule will raise a PreconditionNotMet:

With:
The purpose of the CacheAccess must be compatible with the usage mode of the Cache;
only a Cache that is write-enabled can create a CacheAccess that allows writing.
Violating this rule will raise a PreconditionNotMet.

Problem (4/5):
Section 3.1.6.3.4 on page 3-22 right underneath the table gives an overview of the attributes of the Cache. The first bullet takes three attributes into one description, while everywhere else separate bullets are used for each attribute. This should be no different.

Solution (4/5):
Replace:
·	the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related Publisher (the_publisher) and Subscriber (the_subscriber).

With:
·	the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state)

·	the related Publisher (the_publisher) 

·	the related Subscriber (the_subscriber).

Problem (5/5):

In the description of the disable_updates() operation of the Cache in section 3.1.6.3.4 on page 3-22 still talks about the possibility of updates being interrupted. This 'possibility' was removed in the previous spec revision. An update round will always be finished normally.

Solution (5/5):
Replace:
disable_updates causes incoming but not yet applied updates to be registered for further application. If it is called in the middle of a set of updates (see Listener operations), the Listener will receive end_updates with a parameter that indicates that the updates have been interrupted.
With:
disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account. 

Resolution: 
Revised Text: 
Actions taken:
February 14, 2007: received issue
Discussion: 

End of Annotations:=====
iler: QUALCOMM Windows Eudora Version 7.0.1.0
Date: Wed, 14 Feb 2007 12:25:10 -0500
To: issues@omg.org, data-distribution-rtf@omg.org
From: Juergen Boldt <juergen@omg.org>
Subject: issue 10749 -- DDS RTF issue
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org


This is issue # 10749   From: "Erik Hendriks" <Erik.Hendriks@prismtech.com>


Various typos in section 3.1.6.3.4, Cache

Problem (1/5):
Section 3.1.6.3.4 on the table on page 3-22 errornously states the operations load(), lock() and unlock(), which no longer exist since the previous specification update. They have been removed from the idl as well and figure 3-4, but not here.

Solution (1/5):
Remove load(), lock() and unlock() operations from the table on page 3-22

Problem (2/5):
Section 3.1.6.3.4 on page 3-24 still contains various descriptions about operations that no longer exist, namely load, deref, lock, unlock. All these operations were removed in the previous spec revision.

Solution (2/5):
Remove the following texts:
o explicitly request taking into account the waiting incoming updates (load). In case
updates_enabled is TRUE, the load operation does nothing because the updates are
taken into account on the fly; in case updates_enabled is FALSE, the load operation
'takes' all the waiting incoming updates and applies them in the Cache. The load
operation does not trigger any listener (while automatic taking into account of the
updates does - see Section 3.1.6.4, "Listeners Activation," on page 3-41 for more
details on listener activation) and may therefore be useful in particular for global
initialization of the Cache.
o transform an ObjectReference to the corresponding ObjectRoot. This operation can
return the already instantiated ObjectRoot or create one if not already done. These
ObjectRoot are not modifiable (modifications are only allowed on cloned objects
attached to a CacheAccess in write mode).
o lock the Cache with respect to all other modifications, either from the infrastructure
or from other application threads. This operation ensures that several operations can
be performed on the same Cache state (i.e., cloning of several objects in a
CacheAccess). This operation blocks until the Cache can be allocated to the calling
thread and the waiting time is limited by a time-out (to_in_milliseconds). In case
the time-out expired before the lock can be granted, an exception (ExpiredTimeOut)
is raised.
o unlock the Cache.

Problem (3/5):
In section 3.1.6.3.4 on page 3-24 in the middle of the page an indent is missing for the following text. And the paragraph is also ended with a ':', which should be a '.'. In the middle of the text, behind the first bold, italic word Cache it also has a ':', which should be a ';'

Solution (3/5):
Replace:
The purpose of the CacheAccess must be compatible with the usage mode of the Cache:
only a Cache that is write-enabled can create a CacheAccess that allows writing.
Violating this rule will raise a PreconditionNotMet:

With:
The purpose of the CacheAccess must be compatible with the usage mode of the Cache;
only a Cache that is write-enabled can create a CacheAccess that allows writing.
Violating this rule will raise a PreconditionNotMet.

Problem (4/5):
Section 3.1.6.3.4 on page 3-22 right underneath the table gives an overview of the attributes of the Cache. The first bullet takes three attributes into one description, while everywhere else separate bullets are used for each attribute. This should be no different.

Solution (4/5):
Replace:
·       the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state), as well as the related Publisher (the_publisher) and Subscriber (the_subscriber).

With:
·       the state of the cache with respect to the underlying Pub/Sub infrastructure (pubsub_state)

·       the related Publisher (the_publisher) 

·       the related Subscriber (the_subscriber).

Problem (5/5):

In the description of the disable_updates() operation of the Cache in section 3.1.6.3.4 on page 3-22 still talks about the possibility of updates being interrupted. This 'possibility' was removed in the previous spec revision. An update round will always be finished normally.

Solution (5/5):
Replace:
disable_updates causes incoming but not yet applied updates to be registered for further application. If it is called in the middle of a set of updates (see Listener operations), the Listener will receive end_updates with a parameter that indicates that the updates have been interrupted.
With:
disable_updates causes incoming but not yet applied updates to be registered for further application, any update round in progress will be completed before the disable updates instruction is taken into account. 

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