[OASIS Issue Tracker] Updated: (SCACANDCPP-1) Preserving state in passivated Conversational scopes

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

     [ http://tools.oasis-open.org/issues/browse/SCACANDCPP-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bryan Aupperle updated SCACANDCPP-1:
------------------------------------

          Component/s: C++ Specification
    Affects Version/s: Version 1.1

> 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
>          Components: C++ Specification
>    Affects Versions: Version 1.1
>            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