[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [sca-c-cpp] NEW ISSUE: Preserving state in passivated Conversational scopes.
This seemed like it was complex enough that we should probably deal with it as a separate issue from the conformance statement review. TARGET: C++ C&I Spec DESCRIPTION: Section 2.3.4 of the C++ spec discusses the possibility of passivating a service implementation instance in a long-running conversation, however it doesn't define how implementation state should be preserved. PROPOSAL: The following is an initial take at replacing/clarifying the last sentence of the first paragraph of section 2.3.4: "If this occurs, the runtime MUST provide a mechanism for preserving instance state information. An SCA runtime MUST NOT passivate an implementation instance if it cannot preserve implementation state." Does that help to clarify the expected behavior? This still leaves us with the responsibility for writing conformance tests for this scenario, which may be difficult. An alternative might be to wash our hands of passivating implementation instances (replacing the last two sentences). "This specification does not define a mechanism for passivating long-running conversational implementation instances. An implementation MAY provide a mechanism for passivating implementation instances." A third option might be to define in the C++ API a mechanism to allow users to preserve state. One approach would be to provide a simple API that a service implementor could derive from and implement in order to provide persistence/restoration capabilities on their implementations. class PersistableService { virtual ~PersistableService(); /** * Returns a string containing the serialized state associated * with this service. */ virtual std::string persistState(void) = 0; /** * Reads the state information for this service from the * serialized state information in \a state. */ virtual void restoreState(const std::string& state) = 0; }; Alternatively we could add additional annotations to allow the user to identify their own persist/restore methods (we'd still probably need to specify the return type/parameters of the methods). This would restrict how a runtime could support passivating a service (by requiring this mechanism), but it will also ensure that there's a portable mechanism for persisting user state across runtime implementations. Thanks. David. -- David Haney -- Chief Architect, Hydra Products -- Rogue Wave Software -- http://www.roguewave.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]