Richard,
My interpretation is that a Producer should not throw
StateChangeRequired fault when the portletStateChange flag is set to
cloneBeforeWrite or readWrite. Firstly, the Producer has a chance to
make state changes. Secondly, with the interpretation you present, the
consumer first makes a call with cloneBeforeWrite, gets a fault, clones,
and then repeats the pbia. This is more work for the Consumer and more
waiting time for the end user.
Subbu
Richard Jacob wrote:
>
>
>
>
> Hi folks,
>
> I have some questions regarding cloning and would like to hear your
> interpretations.
> Especially I'm interested in the cloneBeforeWrite handling.
>
> In the spec, section 6.3.2, page 43, lines 9-19 we say the following about
> the portletStateChange flag set to cloneBeforeWrite:
> 1. if Producer clones the portlet first, persistent state changes are
> handled as if readsWrite was set
> 2. if Producer does not clone the portlet, persistent state changes are
> handled as if readOnly was set
>
> My interpretation here is that implicit cloning on the Producer side is
> optional, i.e. if cloneBeforeWrite is set, the Producer can choose not to
> clone implicitly and throw a stateChangeRequired fault in the same way as
> if would do so for readOnly set (of course in the case where persistent
> state change is necessary).
> In this case the Consumer is "forced" to explicitly clone the portlet first
> and then to proceed.
> So my questions are:
> 1. can a Producer throw a StateChangeRequired fault on a
> performBlockingInteraction() if the portletStateChange field was set
> cloneBeforeWrite?
> 2. Should in general Consumers interpret this StateChangeRequired fault as
> an signal to explicit clone a portlet prior to proceeding?
>
> Mit freundlichen Gruessen / best regards,
>
> Richard Jacob
> ______________________________________________________
> IBM Lab Boeblingen, Germany
> Dept.8288, WebSphere Portal Server Development
> Phone: ++49 7031 16-3469 - Fax: ++49 7031 16-4888
> Email: mailto:
>
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/wsrp-interop/members/leave_workgroup.php.
>
