Good point. It does simplify Alejandro's scenario for the Consumer.
Subbu
Rich Thompson said the following on 11/19/2003 11:58 AM:
>
> I would encourage the Producer in such a scenario to only use the cookie
> and never return a sessionID. This eliminates duplicate information that
> can cause all sorts of issues.
>
> Rich
>
>
> *Alejandro Abdelnur <>*
> Sent by:
>
> 11/19/2003 01:43 PM
>
>
> To
>
> cc
>
> Subject
> Re: [wsrp-interop] on initCookies and sessionID
>
>
>
>
>
>
>
>
> This was exactly the scenario we are facing. The problem is that things
> get weird (out of synch) if the consumer invokes the producer in
> parallel for 2+ portlets and one of the throws a cookie or a session
> fault.
>
> Alejandro
>
> On Wednesday, November 19, 2003, at 06:08 AM, Subbu Allamaraju wrote:
>
> >
> > I would like to note that a Producer requring perUser init cookies may
> > choose to use the same cookie for both cases (ie return a session
> > cookie in response to an initCookie call, and return the same session
> > ID in the pbia response).
>
> > In this case, my interpretation is that
> >
> > (a) Producer returns InvalidCookie fault when the cookie from the
> > request (when HTTP binding is used) is no longer valid.
> >
> > (b) Poducer never returns InvalidSession fault (since this has the
> > same affect, atleast for the Producer), and reinvoking initCookie()
> > and resupplying data stored in sessions lets the Producer/portlet
> > recover from session loss.
> >
> > For the consumer,
> >
> > (a) If the Consumer is strict about cookies, it does not send expired
> > cookies to the Producer. So, after the cookie times out, it
> > automatically invokes initCookie().
> >
> > (b) If the Consumer is not strict, it may send an expired cookie to
> > the Producer. The producer then returns InvalidCookie fault.
> >
> > Subbu
> >
> >
> > Rich Thompson said the following on 11/19/2003 05:52 AM:
> >> My take on the answers:
> >> First, overall comments: Private sessions between the end-user and
> >> particular instances of a portlet are modeled in the protocol via
> >> sessionID. It was also recognized that various systems have reasons
> >> to use a cookie to carry session information, though these types of
> >> sessions are not always unique to a portlet instance. As a result,
> >> these two tend to closely parallel each other while never being
> >> linked.
> >> Q1. Is there any required relationship between the cookies returned
> >> by initCookie and the sessionID returned by the markup interface
> >> calls?
> >> A1. No, though if the CookieProtocol is perUser then they do carry
> >> the same semantics.
> >> Q2. If a call returns an InvalidCookie fault, should the consumer
> >> discard the sessionID?
> >> A2. No, the cookies are independent of the private sessionID and are
> >> not necessarily related to a session at all.
> >> Q3. If a call returns an InvalidSession fault, should the consumer
> >> call initCookie again?
> >> A3. same as A2.
> >> Sorry if the fault descriptions are confusing:
> >> - InvalidSession fault is used only when the private session has
> >> timed out and required data had been cached in the session (templates
> >> or UserContext). If the session did not contain such data or it is
> >> also available via the supplied data on the invocation, the Producer
> >> can simply create a new session and include it in the returned data
> >> structure for future invocations from the Consumer.
> >> - InvalidCookie fault is used only when the cookies established by
> >> initCookie become invalid. This signals to the Consumer the need to
> >> invoke initCookie again. Since some Producers will establish a
> >> session related to these cookies, it would be wise for the Consumer
> >> to resend templates and UserContext when reinvoking the operation
> >> that caused the InvalidCookie fault as this can avoid the next
> >> invocation returning an InvalidSession fault.
> >> Rich
> >> *Alejandro Abdelnur <>*
> >> Sent by:
> >> 11/18/2003 07:02 PM
> >>
> >> To
> >>
> >> cc
> >>
> >> Subject
> >> [wsrp-interop] on initCookies and sessionID
> >>
> >> One of the engineers in my group (punished with implementing WSRP)
> >> came
> >> to me with the following questions and I could not find an answer for
> >> her. I would like to know what is your opinion on this and how are you
> >> handling this scenario.
> >> Thanks
> >> Alejandro
> >> * Producer requires initCookie.
> >> * Consumer uses more than one portlet from the producer for
> >> the portal page of a user.
> >> * initCookie has been called upfront.
> >> * performBlockingInteraction and/or getMarkup have returned a
> >> sessionID
> >> Q1. Is there any required relationship between the cookies returned by
> >> initCookie and the sessionID returned by the markup interface calls?
> >> Q2. If a call returns an InvalidCookie fault, should the consumer
> >> discard the sessionID?
> >> Q3. If a call returns an InvalidSession fault, should the consumer
> >> call
> >> initCookie again?
> >> If the answer is 'no' to all the questions, then the following
> >> sections
> >> of the spec make things more confusing:
> >> P27/L27 "If the Producer returns an InvalidSession fault message after
> >> returning a sessionID, the Consumer MUST NOT resupply that sessionID
> >> on
> >> a subsequent invocation and SHOULD reinvoke the operation that caused
> >> the fault message without any sessionID and supply any data that may
> >> have been stored in the session."
> >> P44/L6 "If at any time the Producer throws a fault message
> >> (“InvalidCookie”) indicating the supplied cookies have been
> >> invalidated
> >> at the Producer, then the Consumer MUST again invoke initCookie() and
> >> SHOULD reprocess the invocation that caused the fault message to be
> >> thrown and include any data that may have been stored in a session
> >> related to a cookie"
> >> P77/Table,Row=InvalidCookie "InvalidCookie Used only when the
> >> environment at the Producer has timed out AND the Producer needs the
> >> Consumer to invoke initCookie() again and resend data that may have
> >> been stored in sessions related to a cookie."
> >> P77/Table,Row=InvalidSession "Used only when a Producer session has
> >> timed out AND the Producer needs the Consumer to invoke resend data
> >> that may have been cached in the session."
> >
> >
> >
> > 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.
> >
>
>
> 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.
>
>
