OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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:MICHAEL.FREEDMAN@oracle.com]
Sent: Tue, July 23, 2002 00:21
To: wsrp-interfaces@lists.oasis-open.org; wsia@lists.oasis-open.org
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-


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC