MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] 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
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-
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC