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] [wsrp][interfaces] Session issues

   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.

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

Powered by eList eXpress LLC