OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-c-cpp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-c-cpp] NEW ISSUE: Preserving state in passivated Conversationalscopes.



This issue has been assigned id CCPP-25 in the Jira system.
See http://www.osoa.org/jira/browse/CCPP-25


Andrew

____________________________________________________________

Andrew Borley
Websphere ESB Development
Tel: 245393 Ext: +44 (0) 1962 815393 Mob: +44 (0) 7971 805547
E-mail: borley@uk.ibm.com
Mailpoint 211, IBM (UK) Ltd, Hursley Park, Winchester, Hants, SO21 2JN
____________________________________________________________


"David Haney" <haney@roguewave.com> wrote on 29/11/2007 16:55:23:

> 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/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]