OK. I misunderstood you.
You raise good points, which I'll have to think
about.
GIl
-----Original Message-----
From: Michael Freedman
[mailto:]
Sent: Wed, July 24, 2002
03:29
Cc: ;
Subject: Re: [wsrp-interfaces]
[wsrp][interfaces] Session issues
Gil,
On
(a): Either I misunderstand you or you misunderstood me. In (a) I
am referring only to the producer. If a producer is maintaining in
memory session state and that producer is running in a multi-node/vm load
balanced J2EE environment then private sessions must be sub-sessions of the
producers shared session as its the shared session that is replicated.
For me (a) has nothing to do with the consumer or the client.
On (b). The issue is again limited to the case where the
producer is running in a multinode/vm load balanced J2EE environment. In
such an environment [if I understand correctly] J2EE is free to dispatch
concurrent requests across all nodes/vms until a session is established.
Once a session is established concurrent requests must go to the same
node/vm. Hence there is a createSession issue. If two concurrent
requests running in different nodes/vms want to establish a session at
the same time, the producer has no way to internally "synchronize" this
creation and guarantee the same ID is used. I.e. for session creation
purposes we need to ensure there is only a single request to the producer not
concurrent requests.
-Mike-
Gil Tayar wrote:
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
replicatedI'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-
