Re: [wsrp] Sessions and Transient Entities

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

Eilon,
  I think your suggestion intermixes 2 different concepts -- that
of session identity and that of instance/entity identity.  My scenario
1 concerns itself with how an instance/entity id can be used to segment
data within a session.  My scenario 2 concerns itself with how distinct
sessions can be established/maintained.  I suggested we don't define
a way for the producer to describe its grouping rules.  Rather a consumer
can choose to support grouping (via a mechanism its free to define) or
leave it up to the consumer to handle internally (via perference/configuration
data).  So in my scenario 2, a consumer isn't responsible for separating
the portlets into different sessions.  It merely is allowed to do
so.  Portlets must assume they aren't running in such environments
-- rather they must assume they run in a shared session world -- hence
they need an ID to do the proper namespacing.  As the consumer doesn't
know this grouping (because it doesn't implement grouping) the producer
must provide its own UI for getting these keys -- i.e. the producer must
provide a configuration/personalization UI that allows a group key to be
specified for each of its portlets -- it can then use this "internal" group
id to key/separate data in the shared session.

Just a long way of saying -- I don't buy your scenario 2.  If the consumer knows the grouping, I would rather the consumer maintain 2 discrete sessions as this allows it to continue to pass the entity id so each entity can maintain entity specific data if necessary (i.e. portlet A, B, B' in the same session/group -- B and B' can keep their data separate).  If the consumer doesn't know the grouping then it controls things just like scenario 1.  The producer is free to define/manage finer granularity as described above.
     -Mike-

Eilon Reshef wrote:

>  Mike,Per
> your recent e-mails, I think that the approach makes sense.The
> only thing that concerns me is that we have two different mechanisms to
> handle what would seem to be a very similar scenario.Scenario
> 1: If there are two occurrences of a single portlet on a page, then
> as you described it the portlet is responsible for segregating the occurrence-specific
> information, using an additional key provided by the portal.Scenario
> 2: If there are two occurrences of a pair of portlets, then suddenly
> the portal is responsible for segregating the two pairs by placing them
> in two separate sessions.(All,
> of course, assuming that the portlets use sessions)The
> idea of the Consumer creating and managing the segregation keys has the
> scalability advantage that you mentioned.Can't
> we use it to handle both scenarios?Namely:In
> scenario 1, where there's portlets A1 and A2, then the portal sends a key
> "1" when displaying A1 and a key "2" when displaying A2. In
> scenario 2, when there's portlet pairs <A1, B1> and <A2, B2>, then
> the portal sends a key "1" when displaying A1 and B1 and the key "2" when
> displaying A2 and B2.This
> would allow the Producer to create and manage the session id (and maybe
> even create them only when needed, instead of explicitly creating them
> up-front as the current draft suggests). The Consumer only has to take
> into account that it may receive (and needs to re-send) a separate session
> id for each one of the keys.Eilon