[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Created: (SCACANDCPP-1) Preserving state in passivated Conversational scopes
Preserving state in passivated Conversational scopes ---------------------------------------------------- Key: SCACANDCPP-1 URL: http://tools.oasis-open.org/issues/browse/SCACANDCPP-1 Project: OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC Issue Type: Bug Reporter: Bryan Aupperle Originally CCPP-25 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. Raised to the OASIS Service Component Architecture / C and C++ (SCA-C-C++) TC in the e-mail at http://lists.oasis-open.org/archives/sca-c-cpp/200711/msg00025.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]