Persistent State Service Avatar
  1. OMG Specification

Persistent State Service — Closed Issues

  • Acronym: PSS
  • Issues Count: 33
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Summary

Key Issue Reported Fixed Disposition Status
PSSM_-6 Notation for entry, do and exit behaviors is wrong PSSM 1.0b1 PSSM 1.0 Deferred closed
PSSM_-3 PSSM implementation shall conform to bUML PSSM 1.0b1 PSSM 1.0 Deferred closed
PSSM_-1 Tests that send multiple signals are not correct PSSM 1.0b1 PSSM 1.0 Deferred closed
PSSM_-23 Incorrect transition numbering in Deferred007_Test PSSM 1.0a1 PSSM 1.0 Resolved closed
PSSM_-12 PSSM should align with fUML 1.4 and PSCS 1.2 PSSM 1.0b1 PSSM 1.0 Resolved closed
PSSM_-11 "Join 003" has (invalid) triggers on transitions entering join PSSM 1.0b1 PSSM 1.0 Duplicate or Merged closed
PSSM_-7 In Testcase "Entering 011" T3 is not a completion transition PSSM 1.0b1 PSSM 1.0 Resolved closed
PSSM_-2 Synchronous operation call on an active object ends if the corresponding call event occurrence was deferred PSSM 1.0b1 PSSM 1.0 Resolved closed
PSSM_-4 PSSM shall be aligned with fUML 1.3 and PSCS 1.1 PSSM 1.0b1 PSSM 1.0 Resolved closed
PSSM_-8 "Join 003" test case state machine diagram appears to be invalid PSSM 1.0b1 PSSM 1.0 Resolved closed
PSSM_-10 Typos in "Note" section of "9.3.3.12 Transition 019" PSSM 1.0b1 PSSM 1.0 Resolved closed
PSSM_-9 Example state machine appears to violate UML constraints PSSM 1.0b1 PSSM 1.0 Resolved closed
PSS-29 cross-referencing PSS and CosCollections PSS 1.0b1 PSS 1.0 Resolved closed
PSS-28 PSS storage model and associated object interactions unclear PSS 1.0b1 PSS 1.0 Resolved closed
PSS-24 New PSS Issue: Interface Inheritance PSS 1.0b1 PSS 1.0 Resolved closed
PSS-23 Some others ways to get an abstract storage type reference PSS 1.0b1 PSS 1.0 Resolved closed
PSS-27 New PSS Issue: Private state members PSS 1.0b1 PSS 1.0 Resolved closed
PSS-26 New PSS Issues: Full Scopes for Storage Objects PSS 1.0b1 PSS 1.0 Resolved closed
PSS-21 usage of user defined catalogs unclear. PSS 1.0b1 PSS 1.0 Resolved closed
PSS-25 New PSS Issue: Is the PSDL Grammar Too Complicated? PSS 1.0b1 PSS 1.0 Resolved closed
PSS-22 no parameter order for operations _create(...) defined PSS 1.0b1 PSS 1.0 Resolved closed
PSS-20 Mistakes in CosPersisentState.psdl presented in chapter 11. PSS 1.0b1 PSS 1.0 Resolved closed
PSS2-1 PSS-FTF: PSDL grammar problems PSS 1.0 PSS 2.0 Resolved closed
PSS-14 PSS FTF issue: PSS & Thread-Safety PSS 1.0b1 PSS 1.0 Resolved closed
PSS-13 PSS FTF issue: ConnectorRegistry made redundant by PSS 1.0b1 PSS 1.0 Resolved closed
PSS-12 PSS-FTF issue: Need additional C++ helpers PSS 1.0b1 PSS 1.0 Resolved closed
PSS-11 C++ mapping for PSDL storage object references PSS 1.0b1 PSS 1.0 Resolved closed
PSS-10 The use of italics is wrong in some grammar rules PSS 1.0b1 PSS 1.0 Resolved closed
PSS-17 PSS: factory_dcl syntax PSS 1.0b1 PSS 1.0 Resolved closed
PSS-16 PSS FTF: Read-only operations on storage objects PSS 1.0b1 PSS 1.0 Resolved closed
PSS-15 PSS FTF issue: Restrictions on PSDL concrete types PSS 1.0b1 PSS 1.0 Resolved closed
PSS-18 PSS: Mapping for catalogs and abstract storage homes PSS 1.0b1 PSS 1.0 Resolved closed
PSS-19 PSS: provides_dcl production misnamed PSS 1.0b1 PSS 1.0 Resolved closed

Issues Descriptions

Notation for entry, do and exit behaviors is wrong

  • Key: PSSM_-6
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The correct notation is for example:

    entry/Activity entry

    All the diagrams in PSSM show instead

    /entry Activity entry

    This is confusing and should get changed.
    Also the text in all examples of the UML specification is left justified. It is not mentioned as a requirement, but I think most tools follow this convention. In the PSSM specification the text is centered. I suggest to change it to left justified.
    The effect of Transitions is notated with a colon:

    /Activity: effect.

    I think that should also be consistent. Either remove the colon, or use it with state behaviors as well.
    As an additional suggestion: In most cases it is not relevant for the test case, that an activity is called. The string "Activity" could be left out to keep the diagram less cluttered.

  • Reported: PSSM 1.0b1 — Tue, 3 Apr 2018 15:31 GMT
  • Disposition: Deferred — PSSM 1.0
  • Disposition Summary:

    Defer

    This is the result of a bug in the Papyrus tooling used to generate the diagrams. Since the notation currently in the specification is still clear, if not entirely correct, the FTF proposes to defer the resolution of this issue until a fix is available for Papyrus.

  • Updated: Mon, 1 Apr 2019 18:41 GMT

PSSM implementation shall conform to bUML

  • Key: PSSM_-3
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Jeremie Tatibouet)
  • Summary:

    The behavioral part of the PSSM semantic model is specified using Java syntax. The subset of Java that is used does not always conform to the mapping rules defined in Annex A of fUML between Java and Activities.

    Examples:

    1. Usage of index starting from 0 instead of 1 in StateActivation::hasCompleted operation.
    2. Constructor call with arguments in StateMachineEventAccepter::accept operation.
    3. Usage of an iterative for loop instead a parallel for loop in StateActivation::enterRegion operation.
  • Reported: PSSM 1.0b1 — Thu, 13 Apr 2017 13:02 GMT
  • Disposition: Deferred — PSSM 1.0
  • Disposition Summary:

    Defer

    The FTF agrees that this issue should be resolved, but it is deferred to the first RTF due to lack of time. Further, while the formal structure of fUML base semantics requires the use of bUML, the standard is still clear as it is on the functionality being specified, even if not fully conformant to bUML.

  • Updated: Mon, 1 Apr 2019 18:41 GMT

Tests that send multiple signals are not correct

  • Key: PSSM_-1
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    Any test in the PSSM test suite with a test driver that sends multiple signals to the model being tested may not currently be properly allowing all possible execution traces. This is because itt cannot, in general, be presumed that event occurrences are received in the order they are sent, even if they are all sent from the same thread. This was always true in fUML (per the statement of “the semantics of inter-object communications mechanisms” in subclause 2.4 of the spec), but it is completely, formally clear in fUML 1.3, in which EventOccurrence is an active class, such that all event occurrences are sent concurrently with each other.

    For example, consider test Transition 007 (described in subclause 9.3.3.2 of the PSSM beta spec). The tester behavior for this test sequentially sends three signal instances: AnotherSignal, Continue and Continue again. However, while these signals are sent sequentially, there is no guarantee they will be received by the tested state machine in the same order. For example, one of the Continue signal instances could be received before the AnotherSignal instance, which would cause the state machine (as shown in Fig. 9.12) to take transition T3 to S2 and never get to S3.

    Rather than try to capture all the possible traces that should be allowed by the such tests a s currently modeled, it would be better to modify the tests so that they should only produce the trace that is currently suspected. This can be done by having the state machine under test send signals back to the tester, in order to coordinate the sending of sequential signals. For example, in the case of Transition 007, the state machine could send signals back to the tester as part of the doTraversial behaviors for transitions T1 and T2. The test behavior would then have to include accept event actions in order to wait between the send signal actions. (Of course, to allow the test to send signals back to the tester, either the Tester/Target association in the test architecture would need to be made bidirectional, or some signaling mechanism would need to be provided through the SemanticTest class.)

  • Reported: PSSM 1.0b1 — Tue, 5 Dec 2017 23:11 GMT
  • Disposition: Deferred — PSSM 1.0
  • Disposition Summary:

    Defer

    While the FTF agrees that this is an issue that should be resolve, it is deferred to the first RTF due to lack of time.

  • Updated: Mon, 1 Apr 2019 18:41 GMT

Incorrect transition numbering in Deferred007_Test

  • Key: PSSM_-23
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Jeremie Tatibouet)
  • Summary:

    The classifier behavior of the test Deferred007 is specified as a state machine. Transitions in this state machine are numbered. However the numbering goes jumps from T3 to T6.

  • Reported: PSSM 1.0a1 — Wed, 7 Nov 2018 15:55 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Resolution of issue PSSM_-23

    The resolution requires:

    1. An update of the specification document. Indeed Figure 9.101, the generated trace, the note and the RTC steps overview need to updated.
    2. An update of the test suite model.
  • Updated: Mon, 1 Apr 2019 18:19 GMT
  • Attachments:

PSSM should align with fUML 1.4 and PSCS 1.2

  • Key: PSSM_-12
  • Status: closed  
  • Source: Model Driven Solutions ( Mr. Ed Seidewitz)
  • Summary:

    The fUML 1.4 and PSCS 1.2 specifications have now been completed. These updates make no functional changes to fUML or PSCS, but they migrate those standards to UML 2.5.1, which is consistent with PSSM. Therefore, PSSM should align with fUML 1.4 and PSCS 1.2, rather than fUML 1.3 and PSCS 1.1.

  • Reported: PSSM 1.0b1 — Fri, 26 Oct 2018 13:07 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Update specification for fUML 1.4 and PSCS 1.2

    Since fUML 1.4 and PSCS 1.2 are based on UML 2.5.1, it is no longer necessary for the PSSM specification to include fUML and PSCS syntax and semantics files based on UML 2.5.1. Instead, the PSSM syntax, semantics and test suite should just use UML 2.5.1, fUML 1.4 and PSCS 1.2.

    The normative references in the specification document need to be updated to fUML 1.4 and PSCS 1.2. In addition, since both the fUML and the PSCS specification documents are now re-organized to follow UML 2.5.1, any subclause references to the fUML and PSCS documents need to be updated.

  • Updated: Mon, 1 Apr 2019 18:19 GMT

"Join 003" has (invalid) triggers on transitions entering join

  • Key: PSSM_-11
  • Status: closed  
  • Source: AGI ( Daniel Yankowsky)
  • Summary:

    According to the UML 2.5.1 spec, there's a constraint `join_segment_guards` which prohibits transitions whose target is a join pseudostate from having guards or triggers (the constraint's scope is larger than its name would imply). But the sample state machine "Join 003" has triggers on the two transitions entering the join.

    Essentially, as I read the UML spec, transitions leading to joins can only be triggered by completion events.

    I don't think that restriction is necessary, and can be trivially worked around (make a composite state with a triggered transition entering the final state). But this state machine does appear to violate that constraint.

  • Reported: PSSM 1.0b1 — Thu, 20 Sep 2018 18:16 GMT
  • Disposition: Duplicate or Merged — PSSM 1.0
  • Disposition Summary:

    Merge with PSSM_-8

    This issue relates to the same element of the same test case, Join 003, as issue PSSM_-8. The two issues can therefore be resolved together.

  • Updated: Mon, 1 Apr 2019 18:19 GMT

In Testcase "Entering 011" T3 is not a completion transition

  • Key: PSSM_-7
  • Status: closed  
  • Source: oose Innovative Informatik eG ( Mr. Axel Scheithauer)
  • Summary:

    The text says:

    The S1 completion event is then used to trigger transition T3.

    Actually transition T3 has an event "Continue" in the diagram and will not react to a completion event.

  • Reported: PSSM 1.0b1 — Tue, 3 Apr 2018 15:35 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Resolution of issue PSSM-7

    Entering 011 has a transition T3 that is not a completion transition. The text describing the interpretation of this transition is inconsistent since it considers T3 has a completion transition.

    This issue is only related to the text. Indeed the table describing each RTC step performed during the execution of the test is consistent with the model (i.e., it consider T3 as a transition triggered by the acceptance of a Continue event occurrence).

  • Updated: Mon, 1 Apr 2019 18:19 GMT

Synchronous operation call on an active object ends if the corresponding call event occurrence was deferred

  • Key: PSSM_-2
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Jeremie Tatibouet)
  • Summary:

    FUML 1.3 provides a support for the CallEvent semantics. When an object performs a synchronous operation call on an active object then a call event occurrence is placed in the event pool of the target (i.e. the active object that is the target of the call). While the target has not accepted the call and the RTC initiated by the acceptance is not completed, the execution thread in which the caller executes remains suspended.

    In PSSM context, the target of the call can be an active object whose executing a classifier behavior described thanks to a state machine. This state machine can have states that declare a call event as being deferred. This means that when the state is active and such call event is dispatched then it is going to be accepted by the state machine. The acceptance leads the call event occurrence to be placed in the deferred event pool of the active object.

    The problem here is that since the call event was deferred, this implies the operation call was not performed by the target. Hence the caller shall not be released before the call event gets "undeferred" (i.e., return back to the regular event pool). However, this is not what is specified in the StateMachineEventAccepter (see section 8.5.2 in [PSSM 1.0b]) semantics. Indeed, the acceptance of the call event occurrence systematically leads to release the caller. Instead, the caller shall only get released if the call event occurrence is used to trigger one to many transitions.

    The problem can be highlighted through the test case Deferred007_Test provided through the PSSM test suite.

    In this test, the call event occurrence corresponding to the op operation is dispatched when in configuration S1. This implies the state machine accepts and defers the event occurrence. At the end of the RTC step, the tester (i.e., the object that emitted the call) shall remain suspended. This shall be maintained until the end of the RTC in which the transition T6 is fired. To demonstrate this semantics, Deferred007 Test shall be refactored.

  • Reported: PSSM 1.0b1 — Mon, 15 May 2017 15:47 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Update the StateMachineEventAccepter and test Deferred 007.

    Rules that constrain the acceptance of an event by a state machine are specified in the accept operation of class StateMachineSemanticVisitor. The specification of this operation needs to be updated to ensure that the caller of an operation gets released only when the corresponding call event occurrence is accepted, not when it is deferred.

    In addition, the test Deferred007_Test must be updated because it currently does not enable the assessment of the combined usage of a call event and deferral semantics. Indeed, as soon as S1 is deferred, the tester (i.e., the entity providing the stimulus) is suspended until the call event occurrence for the operation op is un-deferred and accepted. As Deferred007_Test will never receive a Continue signal event occurrence (since the tester is suspended), T3 will never have a chance to be fired, hence the state machine (and so the test) will remain stuck forever.

    The issue can be resolved by giving S1 a do-activity behavior that is responsible for sending the Continue signal event occurrence to the test (i.e., the instance of Deferred007_Test). The Continue signal event occurrence will then be accepted by the state machine, T3 will be triggered and the call event occurrence will be un-deferred. This un-deferred event occurrence will then be used to trigger T6. Note, however, that this solution will only work if the call event occurrence is received before the Continue event occurrence.

  • Updated: Mon, 1 Apr 2019 18:19 GMT
  • Attachments:

PSSM shall be aligned with fUML 1.3 and PSCS 1.1

  • Key: PSSM_-4
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Jeremie Tatibouet)
  • Summary:

    PSSM is not compatible with fUML 1.3 and PSCS 1.1. This is the consequence of the changes introduced by FUML13-23, FUML13-25, FUML13-16, FUML13-1, FUML13-60 and PSCS11-6. The description below provides an overview of the changes that must be performed in the PSSM semantic model in order to make PSSM comptabile with fUML 1.3 and PSCS 1.1. Note that these changes will also require an update of the PSSM document.

  • Reported: PSSM 1.0b1 — Thu, 13 Apr 2017 12:24 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Update PSSM for fUML 1.3

    There are four categories of changes needed to align PSSM with fUML 1.3 and PSCS 1.1:

    1. Changes to the signature of the Object::send operation (see [fUML 1.3], 8.3.2.2.19, and issue resolution FUML13-23)
      This requires adjusting the implementation of DoActivityContextObject, which redefines the inherited send operation.
    2. API changes introduced in the EventOccurrence class (see issue resolutions FUML13-25, FUML13-1, and FUML13-60)
      These API changes impact the specification of the trigger-matching semantics of CompletionEventOccurrence and DeferredEventOccurrence (see [PSSM 1.0b], 8.5.9). Specifically, a completion event cannot match a trigger since it is used to only trigger transitions with no triggers, and a deferred event occurrence merely delegates to the matching semantics of the deferred event. fUML now also provides the capability for an EventOccurrence to be sent through its own execution thread, but neither the CompletionEventOccurrence nor the DeferredEventOccurrence use this capability. Finally, the alignment with the new EventOccurrence API enables the refactoring of the code of StateActivation (canDefer, defer and notifyCompletion operations), SM_ObjectActivation (registerCompletionEvent operation), TransitionActivation (canFireOne and hasTrigger operations), StateMachineEventAccepter (isDeferred operation) and StateMachineSemanticVisitor (removal of the match operation).
    3. Introduction of class CS_EventOccurrence in PSCS (see [PSSM 1.0b], 8.5.1.2.7, and issue resolution PSCS11-6)
      This requires refactoring EventTriggeredExecution (see [PSSM 1.0b], 8.5.10.1), StateMachineEventAccepter (see [PSSM 1.0b], 8.5.2) and SM_OpaqueExpressionEvaluation (see [PSSM 1.0b], 8.2) to account for the possibility of receiving an CS_EventOccurrence .
    4. Handling of call events in fUML (see [fUML 1.3], 7.3.3 and 8.8, and issue resolution FUML13-16)
      Since fUML 1.3 now includes CallEvent, this no longer needs to be added in the syntax subset for PSSM (see [PSSM 1.0b], 7.5), and CallEventOccurrence and CallEventExecution (and all the associations in which they are involved) can be removed from the semantics for PSSM (see [PSSM 1.0b], 8.5.9).
  • Updated: Mon, 1 Apr 2019 18:19 GMT

"Join 003" test case state machine diagram appears to be invalid

  • Key: PSSM_-8
  • Status: closed  
  • Source: AGI ( Daniel Yankowsky)
  • Summary:

    According to the UML 2.5.1 spec, join pseudostates have a constraint `join_vertex` that ensures that joins have exactly one outgoing transition. Similarly, fork pseudostates have a constraint `fork_vertex` that ensures that forks have exactly one incoming transition. The state machine in "Join 003" includes a heavy bar (which could be interpreted as either a fork or join) that has two incoming transitions and two outgoing transitions. But due to the constraints, it can't be either. In the notation section of the UML 2.5.1 spec, there doesn't seem to be any affordance for a single drawn symbol in the state machine diagram to represent both a fork AND a join instance from the metamodel.

    This diagram appears to violate the `join_vertex` constraint of the metamodel.

  • Reported: PSSM 1.0b1 — Wed, 29 Aug 2018 19:22 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Resolution of issues PSSM_-8 and PSSM_-11

    Agreed. Join003_Test violates constraints join_segment_guards (see subclause 14.5.11.8 in [UML 2.5.1]) and join_vertex (see subclause 14.5.6.7 in [UML 2.5.1]).

    • join_segment_guards implies that a transition targeting a join pseudostate cannot have a guard and trigger.
    • join_vertex implies that a join pseudo state can only have a single outgoing transition.

    Hence, the state machine specifying the test behavior shall be updated as well as the description provided in the subclause 9.3.12.4 of [PSSM 1.0b].

  • Updated: Mon, 1 Apr 2019 18:19 GMT
  • Attachments:

Typos in "Note" section of "9.3.3.12 Transition 019"

  • Key: PSSM_-10
  • Status: closed  
  • Source: AGI ( Daniel Yankowsky)
  • Summary:

    The "Note" section says "Consider the situation where the state machine is in configuration S1[S1.1, S1.2]". This is an impossible configuration; it should read "... in configuration S1[S1.1, S2.1]". The note later says "CE(2.1) will be triggered next", but it should read "CE(2.2) will be triggered next".

  • Reported: PSSM 1.0b1 — Thu, 13 Sep 2018 18:33 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Resolution of issue PSSM_-10

    This is correct.

    • At the third line of the note, S1[S1.1, S1.2] designates an invalid configuration. The intended configuration is S1[S1.1, S2.1].
    • At the last line of the note, the reference to the completion event for S2.1 is invalid. Indeed, this reference must be for the completion event generated for S2.2.

    The changes to perform are limited to the Note in subclause 9.3.3.12 of [PSSM 1.0b].

  • Updated: Mon, 1 Apr 2019 18:19 GMT

Example state machine appears to violate UML constraints

  • Key: PSSM_-9
  • Status: closed  
  • Source: AGI ( Daniel Yankowsky)
  • Summary:

    In this state machine, there is a fork pseudostate with two outgoing transitions. One transition targets a state, while the other transition appears to target a junction pseudostate.

    The UML 2.5.1 spec includes the constraint `fork_segment_state` (14.5.11.8 Constraints) that requires that any transition originating at a fork must terminate at a state. Such a transition is not allowed to terminate at a pseudostate.

    (Incidentally, that particular constraint doesn't seem particularly useful, as any undesirable case that the constraint is trying to prevent could be instead created via default entry into an orthogonal state. But the constraint exists nonetheless.)

  • Reported: PSSM 1.0b1 — Thu, 13 Sep 2018 17:26 GMT
  • Disposition: Resolved — PSSM 1.0
  • Disposition Summary:

    Resolution of issue PSSM_-9

    Agreed. Transition_023 violates constraint fork_segment_state (see subclause 14.5.11.8 in [UML 2.5.1]). Indeed, transition T4 outgoing the fork pseudostate directly targets a junction pseudostate. This is forbidden since the constraints specifies that a transition outgoing a fork pseudostate shall only have a state as a target.

    Hence, the state machine specifying the test behavior shall be updated as well as the description provided in the subclause 9.3.3.15 of [PSSM 1.0b].

  • Updated: Mon, 1 Apr 2019 18:19 GMT
  • Attachments:

cross-referencing PSS and CosCollections

  • Key: PSS-29
  • Legacy Issue Number: 4984
  • Status: closed  
  • Summary:

    Can you add issue cross-referencing PSS and CosCollections.
    Under PSS the work "key" is a reserved work. The CosCollections IDL
    interface
    uses "key" as an operation name under the Operations interface. This
    needs to be changed to something else. I propose changing the operation
    name from "key" to "user_key", reflecting the operation semantics.

  • Reported: PSS 1.0b1 — Mon, 18 Mar 2002 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    purely editorial issue

  • Updated: Fri, 6 Mar 2015 21:38 GMT

PSS storage model and associated object interactions unclear

  • Key: PSS-28
  • Legacy Issue Number: 4074
  • Status: closed  
  • Source: Iconixx ( Thomas Hawker)
  • Summary:

    See the Persistent State Service specification, orbos/99-07-07, section
    5.2.2 (or thereabouts) and section 7.

    I am confused by the storage model "overview" given in section 5.2.2 and
    the more comprehensive treatment in the discussion of the PSDL grammar
    in section 7. The treatment of abstract storage types, homes, and their
    (concrete) implementations is inadequately mapped between the two,
    leading to very unclear semantics. My specific concerns:

    • It is explicitly stated in the text that types, homes, and their
      independent derivation lines are taken from a Java model. Why this
      explicit dependence on Java? Could the submitters not come up with a
      more generic model? Has anyone tried to map these concepts to
      Smalltalk, which doesn't have the same kinds of object representation
      and implementation difficulties as Java and C++? Even though I am a
      Smalltalk expert, my attempts at such a mapping on the proposed model
      have been less than exciting.
    • Although the keyword "abstract" was already defined, why are abstract
      storagetypes and storagehomes "abstract"? They certainly seem
      concrete enough to me, since I would expect that the definition is
      sufficient to generate code equivalent to a valuetype. This
      ambiguates both the general IDL concept of abstraction and concrete
      storagetypes in particular: in all other places abstract types
      represent non-instantiable objects that have no explicit state, and
      it is not at all clear how concrete storagetypes are more "concrete"
      than their abstract relatives.
    • The text indicates that each storagetype must have its own home. Is
      that abstract types, concrete types, or both? Why? Whatever
      happened to polymorphism? If I have multiple storagetypes with
      similar or compatible keying properties, why cannot they all be
      indexed or managed together? I should only require a different home
      if the behavior is different. Even if a language mapping [read that
      as "implementation"] should require such, please don't make that a
      general limitation of the entire model. This is a very useful
      service; let's not restrict its utility or expressive power by
      playing to language limitations.
    • I can understand that you want to keep factory, finder, and
      management behavior separate from storage object behavior, but has
      anyone actually articulated the reasons behind this? (This also
      affects the component model.) What are they? I can see several
      reasons for keeping the factory and finder operations with the
      storagetype, in the same way valuetypes specify factory operations.
      I am also concerned about the apparently artificial complexity
      introduced by requiring parallel derivations of storagetypes and
      storagehomes. Why not generate the homes automatically when needed?
    • Why are keys placed on the storagehome? It would seem more logical
      that you define the keys (as properties) of the storagetype and then
      optionally map those to indices in a datastore, catalog, or
      storagehome. Perhaps we should indicate that, for a particular
      storagetype, certain state members may participate in a key. Why
      isn't at least one key identified as a primary key? Why cannot I
      explicitly define some keys as unique leaving others as non-unique to
      form inverted indices?
    • The text indicates that a concrete storagetype "implements" one or
      more abstract storagetypes. What does this mean? How is this
      accomplished? What are the navigation paradigms, especially for
      multiple storagetypes? What interfaces are expected? This whole
      concept is too weakly specified, and the example in section 10 is too
      simple to explain multiple type implementation.
    • What is the purpose of a catalog and its limitation of singleton
      instances of storagehomes? I can think of reasons why I would want
      multiple instances of a particular storagehome, especially for
      configuration management in the datastores. Can one have multiple
      catalogs, and if so, how do you select one of them, since "by name"
      might not be the best keying property?
  • Reported: PSS 1.0b1 — Tue, 21 Nov 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New PSS Issue: Interface Inheritance

  • Key: PSS-24
  • Legacy Issue Number: 4039
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the PSS specification (orbos/99-07-07), no provision is made for
    [abstract] storagetypes or [abstract] storagehomes to inherit from
    interface definitions. It appears this is an oversight as the omission
    does not seem reasonable. I have found cases in which a home would
    expose the same interface as a storage object, where the home
    subsequently delegates to a specific object however selected.
    Interfaces are a perfect mechanism whereby the operational signatures
    could be standardized, thus eliminating potential errors caused by
    changing one but not the other. Since storage objects are assumed to
    exhibit only local interface behavior, it would not matter whether the
    inheritance was from a local or remote interface definition. This could
    be accomplished using a supports clause in the inheritance specification
    similar to that of valuetypes.

  • Reported: PSS 1.0b1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Some others ways to get an abstract storage type reference

  • Key: PSS-23
  • Legacy Issue Number: 3978
  • Status: closed  
  • Source: Anonymous
  • Summary:

    At this time, the PSDL mapping does not provide a way to create an object
    and to directly get its reference. It means that if you want to have an
    abstract storage type reference, you only have to solution :

    • to use the _create operation from the storage home ( not very flexible )
    • to find an storage type thanks to a find_ref_by_xxx from the abstract
      storage home

    I think that the "factory" mapping should be changed :

    Currently : ( PSS spec, p 56 )

    factory create( accno );

    // it's like
    // Account create( in string accno )

    After changes :

    factory create( accno );
    <pre>
    // it's like
    // Account create( in string accno );
    // ref<Account> create_ref( in string accno );
    </pre>
    Moreover, the catalog currently provides : StorageObject find_by_pid( byte
    [] pid );

    It should be very useful to provide another method : StorageObjectRef
    find_ref_by_pid( byte [] pid );

  • Reported: PSS 1.0b1 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New PSS Issue: Private state members

  • Key: PSS-27
  • Legacy Issue Number: 4042
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the PSDL grammar of the Persistent State Service, orbos/99-07-07,
    state members are merely declared. This makes all such members
    inherently public. What is the rationale behind public-only state
    members? Since storage objects are almost the same as valuetypes, it
    seems an obvious extension that any object, persistent or not, might
    have members that should not be exposed to external objects or even
    derived types. Could this syntax be changed to more closely resemble
    valuetypes? (See also issue 3226 on factory declarators and the
    (currently unnumbered) issues on scoping and grammar complexity.)

  • Reported: PSS 1.0b1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New PSS Issues: Full Scopes for Storage Objects

  • Key: PSS-26
  • Legacy Issue Number: 4041
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In the PSDL grammar of the Persistent State Service, orbos/99-07-07, it
    specifically states that storage definitions are not full scopes. That
    is, they cannot contain type or constant definitions. What is the
    rationalebehind this limitation? Storage types and homes are almost the
    same as valuetypes. It seems perfectly reasonable to have embedded
    types local (encapsulated) to the storage scope that are for internal
    representations only.

  • Reported: PSS 1.0b1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

usage of user defined catalogs unclear.

  • Key: PSS-21
  • Legacy Issue Number: 3252
  • Status: closed  
  • Source: Anonymous
  • Summary:

    To my mind the usage and mapping of user defined catalogs is weakly
    specified. It is not clearly described what is generated and what has to be
    implemented by user. Furthermore it is unclear, how to get access to an
    catalog. Subsequently I consider C++ only. I guess, a new implementation
    class has to be defined for each catalog, inheriting from the mapped class
    of that catalog and from Session. This is necessary to use the operation
    create_basic_session() returning a Session. Further I guess, the parameter
    catalog_type_name of this operation denotes a catalog supported by a prior
    registered user implemented session factory.
    Furthermore chapter 6.2 does not sufficiently explain the parameter
    storage_home_id of operation find_storage_home() from CatalogBase. In
    particular the sentence "In the case of type-specific catalogs (declared in
    PSDL), the provide declarations define valid storage_home_id parameters."
    allows multiple interpretations. What is meant?

  • Reported: PSS 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

New PSS Issue: Is the PSDL Grammar Too Complicated?

  • Key: PSS-25
  • Legacy Issue Number: 4040
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When examining the PSDL grammar in the Persistent State Service,
    orbos/99-07-07, I came too the conclusion that it is over-specified.
    Looking through the IDL grammar, great care is taken to avoid
    overexpansion of the declarator productions. In particular, semantic
    rules are employed to restrict the use of scoped names (acting as types)
    in those situations where a particular use may be invalid. These rules
    could be applied in the same way to the declarator syntax for state
    members. Thus, there is no need to restrict the grammar to "abstract
    storagetype" types for declarators; any scoped name should work as
    elsewhere. Certainly, however, there should be semantic rules that only
    abstract storagetype types may be used in an abstract storagetype
    definition.

  • Reported: PSS 1.0b1 — Tue, 14 Nov 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    rejected

  • Updated: Fri, 6 Mar 2015 20:58 GMT

no parameter order for operations _create(...) defined

  • Key: PSS-22
  • Legacy Issue Number: 3644
  • Status: closed  
  • Source: Anonymous
  • Summary:

    A storagehome is mapped to a C++ class providing _create() member functions.
    In the specification is said, that there have to be parameters for all state
    members of the storagehomes storagetype, but the order is not defined.
    As a solution the parameter list could begin with the base type of the
    storage type, proceed with the leftmost implemented abstract storage type
    and end with the state members defined in the storage type itself. In every
    case the declaration order should be followed.

  • Reported: PSS 1.0b1 — Thu, 25 May 2000 04:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mistakes in CosPersisentState.psdl presented in chapter 11.

  • Key: PSS-20
  • Legacy Issue Number: 3251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    concerning mistakes in CosPersisentState.psdl presented in chapter 11.

    First, the keyword "factory" defined in chapter 7.2.2 is used as parameter
    name in the signature of the operations "register_XXX_factory()". Second,
    the declaration of ConnectorRegistry is not contained in the summary in
    chapter 11.

  • Reported: PSS 1.0b1 — Wed, 26 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS-FTF: PSDL grammar problems

  • Key: PSS2-1
  • Legacy Issue Number: 4644
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    In ptc/01-06-02:

    Production 10, rhs refers to a 'storagetype_local_op_dcl' which is defined
    in production 24 as a 'storage_type_local_op_dcl. Pick one or the other
    and change references as required...

    Production 4 and Production 23 abstract_storagehome_name are defined
    twice still. Remove one and reindex all proceeding productions.

    Add the 'state' keyword to the keywords table it seems to have gone missing
    between edits

    Perhaps a mention that the 'factory' and 'const' keywords are in common
    to PSDL and IDL and that the 'provides' keyword is in common to PSDL
    and CIDL. It might also be worth mentioning that the sharing is syntax only
    as some people may confuse the keyword with the semantics they most
    commonly use it in IDL / CIDL as opposed to the semantics it is employed
    within PSDL...

  • Reported: PSS 1.0 — Fri, 26 Oct 2001 04:00 GMT
  • Disposition: Resolved — PSS 2.0
  • Disposition Summary:

    See http://cgi.omg.org/pub/pss_ftf/vote3.pdf (color BLUE)

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS FTF issue: PSS & Thread-Safety

  • Key: PSS-14
  • Legacy Issue Number: 3186
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The Persistent State Service draft specification does not say anything
    about thread-safety. For portability, it is necessary to define the
    guarantees provided by a thread-safe PSS implementation.

    Proposal
    --------
    A catalog (session or session pool) can be either thread-safe or
    thread-unsafe. A compliant implementation does not need to provide
    thread-safe catalogs.
    All objects provided directly or indirectly by a thread-unsafe
    catalog are thread-unsafe – the application must serialize access
    to any of these objects, typically by using a single thread.

    (1) A storage object incarnation provided by a thread-safe catalog
    is like a struct: concurrent reads are safe and do not require any
    locking by the application; concurrent writes (or a concurrent
    read and a concurrent write) are not thread-safe – the application
    must ensure mutual exclusion to avoid problems.
    Flushing a storage object is like reading this object. 'Refreshing'
    a storage object is like updating it.

    (2) Further, the following Session operations are not thread safe:
    they are not supposed to be called concurrently, and no thread
    should be using the target session (or anything in the target
    session, such as an incarnation or a storage home) when they are
    called:

    Session::free_all
    Session::refresh
    Session::close
    TransactionalSession::start
    TransactionalSession::suspend
    TransactionalSession::end

    OTS operations are however safe; for example one thread can call
    tx_current->rollback() while another thread calls start, suspend or
    end on a session involved in this transaction, or while a thread
    is using storage objects managed by that session.

  • Reported: PSS 1.0b1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS FTF issue: ConnectorRegistry made redundant by

  • Key: PSS-13
  • Legacy Issue Number: 3164
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    The Joint Revised Portable Interceptor submission (document orbos/99-12-02)
    defines a new operation on the ORB interface, register_initial_reference.
    With this operation, there is no need for a separate ConnectorRegistry
    (local) object obtained from ORB::resolve_initial_references.

    In practice, I expect that calls to register_initial_reference will
    occur behind the scene – not in the middle of application code.

    For example with our new ORB (Orbix 2000), it is possible to use
    configuration to control the behavior of resolve_initial_references,
    in particular have resolve_initial_references dynamically load and
    initialize a plug-in. The plug-in per-ORB initialization calls
    register_initial_reference on the given ORB instance.

  • Reported: PSS 1.0b1 — Thu, 23 Dec 1999 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS-FTF issue: Need additional C++ helpers

  • Key: PSS-12
  • Legacy Issue Number: 3163
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    Interfaces and other IDL constructs have lots of helpers that
    storage type don't have. In particular it would be useful to add

    • _out classes
    • _duplicate static functions
    • _downcast static functions
    • a CosPersistentState::release() static function that releases
      a ref-count on the given storage object instance (if not null),
      or releases the given CosPersistentState::StorageObjectRef.
  • Reported: PSS 1.0b1 — Thu, 23 Dec 1999 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

C++ mapping for PSDL storage object references

  • Key: PSS-11
  • Legacy Issue Number: 3162
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    There is a number of problems with the C++ mapping for storage object
    references:

    • abstract storage type references are mapped to abstract C++ classes;
      this implies that references are dynamically allocated and freed,
      and typically handled through pointers.

    The dynamic allocation is expensive and error prone (risk of memory
    leaks), and handling 'smart pointers' through pointers to these smart
    pointers is very unusual.

    • The mapped C++ classes inherit from each other, to mimic the implicit
      widening of regular pointers.
      Using inheritance for this purpose is a mistake, since it does not
      correspond to the behavior of real pointers – if class B derives
      from class A, a B instance is a A, but a B* is not a A*, it is only
      implictly converted into an A*.
      The correct way to provide this implicit widening is through
      conversion operators.

    I propose to change the mapping and adopt concrete 'smart-pointer'
    ref classes, that applications allocate on the stack. The proposed
    mapping is implemented in Orbix2000 beta 2 (available from IONA
    web site).

  • Reported: PSS 1.0b1 — Thu, 23 Dec 1999 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

The use of italics is wrong in some grammar rules

  • Key: PSS-10
  • Legacy Issue Number: 3070
  • Status: closed  
  • Source: Humboldt-Universitaet ( Harald Boehme)
  • Summary:

    The use of italics is wrong in some grammar rules.
    In most cases only the "|" has to be non-itallic.

    In rule 10 local_op_dcl is also italic, but this
    nonterminal is not from IDL it is part of PSDL.

    The spec dosen´t say to wich version of OMG IDL
    refers.

  • Reported: PSS 1.0b1 — Tue, 23 Nov 1999 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS: factory_dcl syntax

  • Key: PSS-17
  • Legacy Issue Number: 3226
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    The draft PSS specification, in section 1.3.2, uses the production
    <factory_dcl>. This production is not defined in the grammar
    summary. Instead, it is later given as

    <factory_dcl> ::= "factory" <identifier> <factory_parameters>
    <factory_parameters> ::=
    "(" <simple_declarator> [

    { "," <simple_declarator> }

    *] ")"

    "(" ")"

    This definition contradicts with the production <factory_dcl> from the
    CORBA components draft (ptc/99-10-04), where it is defined as

    *lt;factory_dcl> ::=
    "factory" <identifier> "(" [ <init_param_decls> ] ")" [
    <raises_expr> ]

    Here, the init_param_decls where introduced together with OBV
    (formal/98-12-01), where each parameter has an "in" direction and a
    type, and a name.

    There is also potential confusion with the init_dcl, which represents
    factories for value types.

    At a minimum, one of the production names should be changed, and it
    should be made clear which syntax is used for the "factory" keyword in
    what context. It would be even better if the syntax for factories is
    always the same.

  • Reported: PSS 1.0b1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS FTF: Read-only operations on storage objects

  • Key: PSS-16
  • Legacy Issue Number: 3192
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    With some object oriented programming languages (C++, Ada95), it is
    possible to specify a method as read-only or read-write.
    For example in C++, a 'const' member function has read-only access
    to the data members of the target object.

    So far in IDL and PSDL, there is no way to mark an operation as
    read-only – this makes sense for interfaces, since a CORBA object
    exposes only operations, not state.
    For stateful objects, such as PSDL storage objects and IDL values,
    being able to specify an operation as read-only would be very
    useful. For example in C++ a 'in storage object' parameter
    could be mapped to a pointer to a const C++ object, which is exactly
    the semantics of 'in'. More generally, writing const-correct program
    in C++ (Ada etc.) with PSS would become possible.

  • Reported: PSS 1.0b1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS FTF issue: Restrictions on PSDL concrete types

  • Key: PSS-15
  • Legacy Issue Number: 3188
  • Status: closed  
  • Source: ZeroC ( Bernard Normier)
  • Summary:

    A number of restrictions on concrete PSDL types have the effect
    to force PSS users to use abstract types. For example keys can
    only be defined on abstract storage homes, so in order to define
    a key (and the implied finder operations), a PSS user needs
    to define an abstract storage type and an abstract storage home.

    Accessing storage objects and storage homes through abstract
    storage types and homes provides flexibility (with some
    PSS implementations this allows you to switch from one PSS
    implementation to another one without recompiling or relinking
    the code that uses the storage objects) but is also more complex
    since it doubles the number of PSDL constructs you need.

    For applications that don't need this flexibility, abstract
    types are overkill – and make PSDL look quite complex to
    understand and use. I propose to review the restrictions
    on concrete types to make them usable without abstract types.

  • Reported: PSS 1.0b1 — Fri, 7 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS: Mapping for catalogs and abstract storage homes

  • Key: PSS-18
  • Legacy Issue Number: 3227
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In section 1.4.2 of the PSS draft, catalogs and abstract storage homes
    are mapped to local interfaces. However, it is not clear how the
    <catalog_body> and the <abstract_storagehome_body> is converted into
    the body of the local interface.

    In particular, the mapping for key and factory_dcl is not
    specified. Apparently, the intent is that the mapping follows the
    rules presented in section "Keys" and "Factory Operations" are applied

    • even though those sections talk about mapping to implementation
      languages, not to a local interface.

    Also, if this mapping in these sections is applied, the resulting
    operations consume and produce "ref<S>" values, which are not legal
    for operations in local interfaces (according to the Core
    specification of local interfaces).

  • Reported: PSS 1.0b1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

PSS: provides_dcl production misnamed

  • Key: PSS-19
  • Legacy Issue Number: 3228
  • Status: closed  
  • Source: Humboldt-Universitaet ( Martin von Loewis)
  • Summary:

    In the PSS draft, a production provides_dcl is used. The same
    production name is also used in the draft Core spec (ptc/99-10-03),
    where it means

    <provides_dcl> ::= "provides" <interface_type> <identifier>

    In the PSS draft, however, it is

    <provides_dcl> ::= "provides" <abstract_storagehome_name>
    <simple_declarator>;

    Because of this conflict, one of the productions must be renamed.

  • Reported: PSS 1.0b1 — Mon, 17 Jan 2000 05:00 GMT
  • Disposition: Resolved — PSS 1.0
  • Disposition Summary:

    accepted

  • Updated: Fri, 6 Mar 2015 20:58 GMT