Mike,
Your discussion on sessions talks about two
problems.
a) our private sessions must be attached to the
servlet session so they can be properly replicated
I'm not sure I see the problem. It is intuitive that
the portlet sessions are viewed as "sub-sessions" of the portal session. Also,
for stateless producers (which are important for us, I believe), the
"markupParams" must be stored in the Consumer's session
anyway.
b) the servlet session must be established before
getMarkup/performAction to guarantee there are no race conditions -- i.e. two
concurrent requests to the same producer can't properly create a single shared
session.
Why not? If both portlets get the same "groupID", they can
"java-synchronize" the creation of the shared session (they need to do a
synchronize only if the session doesn't exist, so this will not impact
performance much - and in any case, if it does impact the producer, then in your
model it is solved by making both parallel requests wait on the finishing of the
"initSession" operation, which is a much longer time).
What we do lose by initSession() is that if a portlet
needs a session only on specific actions and not always, then in this
model it cannot defer the creation of the session, like a lot of applications do
in the Web, and so loses the performance and scalability gains of being
stateless most of the time.
You said that "I don't think we should model the private
session in our protocol. Having two sessions is confusing and
awkward". I
agree with the second sentence - having two sessions is confusing and awkward.
But as discussed in the F2F, I think we came to the conclusion that the
"private" session is more logical and more intuitive in the protocol than the
concept of shared session.
Gil
-----Original Message-----
From: MICHAEL.FREEDMAN
[mailto:]
Sent: Tue, July 23, 2002
00:21
To: ;
Subject: [wsrp-interfaces]
[wsrp][interfaces] Session issues
Folks,
We need to reconsider our modeling of sessions. Recent Application
Servers rely on the HTTP session for load balancing. In the J2EE servlet
world, the servlet specification allows for load balancing of servlet
applications based on the session cookie named JSessionID. The semantics
are as follows: until a session is established (until there is a cookie)
an application server can dispatch requests across VMs/Nodes as it sees
fit. Once a session is established, the specification requires that all
concurrent requests be routed to the same node. J2EE furthermore allows
sessions to be replicated across nodes ensuring failover consistency. In
J2EE app servers it is only the servlet session that is replicated, hence it
becomes the unit for reliably maintaining state across requests.
The significance is that for those of us wanting to run WSRP
Portlets in a J2EE servlet environment we need to establish and transmit the
HTTP servlet session cookie. This impacts our protocol in the following
way:
a) our private sessions must be attached to
the servlet session so they can be properly replicated
b) the servlet session must be established before getMarkup/performAction to
guarantee there are no race conditions -- i.e. two concurrent requests to the
same producer can't properly create a single shared
session.
Because of these conditions, I suggest we
revert to the semantics we defined before the
F2F.
sessionId,
timeouthint = initSession(); The producer indicates in its meta data
whether a session is required. If required the consumer must call
initSession() before any call that requires a sessionId. The
initSession() is called once for the group of portlets intended to be
maintained within the session.
As for the other calls
that receive sessionIds, we need to decide how to handle the timeout
situation. As the J2EE servlet environment requires all concurrent
requests running in a session (using a session cookie) run in the same VM, it
is safe for us to allow the producer to reestablish the session and return
it. However, I don't know what other non-Java environments do and since
the producer must still deal with the hassle of concurrent session creation, I
suggest all these other methods merely return exceptions indicating the
session has expired. The consumer must then recall initSession(), and
retry the operation. If one wants to optimize this we could redefine
initSession() so a consumer could call it at anytime (with the current
sessionId) -- and the producer either merely returns the current valid ID or
creates a new one -- i.e. as the initSession returns a hint of how long the
session is maintained between requests, the consumer can use this information
to call initSession() when it thinks it might need to.
Finally, because the shared type session is being represented, I don't think
we should model the private session in our protocol. Having two sessions
is confusing and awkward. In addition because (at least in the J2EE
environment), the private session must be maintained within the servlet
(shared) session, the producer mapping will have to exist anyway -- and so
rather we should reduce the burden on the consumer in maintaining extra
state. The implication of all this is the consumer will now have to send
an id to the producer that it can use as a key for its private session
data.
-Mike-
