[wsrp-interfaces] [wsrp][interfaces][Fwd: Possibilities for supportingload balanced Producers]

[Michael Freedman <Michael.Freedman@oracle.com>]

More background on sessions for discussions tomorrow.  Thanks Rich.
    -Mike-

--- Begin Message ---

• From: "Rich Thompson" <richt2@us.ibm.com>
• To: Michael.Freedman@oracle.com, mike_freedman@yahoo.com
• Date: Wed, 31 Jul 2002 14:57:32 -0400

We began talking about how the protocol supports Producers operating in a
load balanced environment. The problem scenario also includes the Consumer
exploiting shared sessions and executing concurrent requests to the
Producer. Should two or more concurrent requests be to entities in the same
shared session that each try to allocate the shared session, but were
distributed to different nodes in the cluster by the load-balancing system
then the J2EE spec will be violated (namely that concurrent requests
accessing the same session be directed to the same cluster node). Possible
solutions include:

1) Optional explicit life cycle for current session concept (private
sessions). This eliminates the issue by serializing the creation of
sessions for entities within each shared session (though distinct shared
sessions may be inited concurrently). The downside is that this introduces
a serialized sequence of calls when the entities are first accessed leading
to a potential performance issue with loading the first page.

2) Expose shared sessions as first class members of the protocol with an
explicit lifecycle. This restricts the number of roundtrips imposed by #1
as only one per shared session is required. The downside is the explicit
inclusion of shared sessions in the protocol (contradicts F2F decision
regarding these being a short term imperative rather than a long term
solution). This also introduces the difficulty of having 2 session concepts
explicit in the protocol. The additional verbiage to explain when a
developer should use each would not be desirable.

3) Replace current private session concept with a shared session concept.
The eliminates the issues of exposing 2 session concepts, but goes against
the F2F view that the private session was the desirable concept.

4) Require that the Producer manage itself in a manner that does not expose
this issue to the Consumer. Andre Kramer sent an email to the list on
07/29/2002 at 06:26 AM providing techniques that could address this in a
transparent manner. In essence, there is a transport level issue that
Consumers are going to have to deal with related to returning the correct
information at the transport level at appropriate times. (This issue arises
because the Consumer is multiplexing users to the Producer on top of a
protocol intended to connect the two parties directly). For http this
requires relating cookies set by the Producer to the End-User and resending
them when communicating with the entity. The Producer would have to manage
request forwarding when it attempts to create a session (because the
Consumer did not supply it), but finds that one already exists in its
SessionManager.


I prefer #4 as this keeps the complexity at the source that can best deal
with it rather than bleeding it up into the protocol.

--- End Message ---