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."
