[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsrp] [interfaces] session creation
Carsten, The default case would be one entity per producer. But this is controlled by the consumer, for a given producer there would be one session per 'transient common ID' (as described in my email). If needed, it's the responsibility of the producer to isolate portlets from each other in a single session, this could be done using a namespace or different stores altogether. In the case of batch processing you described, where no session exists, the consumer would make the request using a 'transient common ID', if a portlet creates a session, this session will be tagged with the 'transient common ID'. Other portlets of the batch will be able to find the already created session because the have the 'transient common ID'. It is non-trivial logic but I wouldn't say that is rocket science. I agree with your statement that a consumer could have multiple sessions with a producer. I do not understand what you are trying to describe with 'one way to share session data between different producers...' in the context of the current discussion. Regards. Alejandro Carsten Leue wrote: >Alejandro - > >in your description of the scenario it is unclear to me how many PSessions >exist. One per entity or one per producer? >If there is one per entity there would be no possibility to share session >data between entities. As we have as a requirement that it should be >possible to share session data, this cannot be the case. >If there is only one PSession per producer that is returned implicitly this >intoduces some problems (from my point of view): >- the namespacing burden is put on the producer. To isolate the portlets >inside the (global) session the producer would have to prefix the >parameters for each portlet that writes into this session. If the consumer >had created separate sessions for sets of communicating portlets this would >not have been the case. How can session data be shared in this case? >- assume the case that multiple portlets should be rendered in parallel >(batch processing) but no session exists. Which one of the portlets to be >rendered should create the session? The producer would have to provide >non-trivial logic to always use the same session >- one way to share session data between different producers would be that >get consumer calls getProperties on the first session and setProperties on >the second one (just copies the session data). In the case that there was >only one session per producer the client needs an additional way to specify >what subset of session data to copy. If the consumer could maintain >multiple sessions per producer this granularity would solve the problem >automatically. > >For these reasons I think that the ability to explicitly create sessions >significantly simplifies the data handling. > >Best regards >Carsten Leue > >------- >Dr. Carsten Leue >Dept.8288, IBM Laboratory Böblingen , Germany >Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401 > > > >|---------+----------------------------> >| | Alejandro | >| | Abdelnur | >| | <alejandro.abdeln| >| | ur@sun.com> | >| | | >| | 06/11/2002 05:51 | >| | AM | >| | Please respond to| >| | Alejandro | >| | Abdelnur | >| | | >|---------+----------------------------> > >---------------------------------------------------------------------------------------------------------------------------------------------| > | | > | To: wsrp@lists.oasis-open.org | > | cc: | > | Subject: [wsrp] [interfaces] session creation | > | | > | | > >---------------------------------------------------------------------------------------------------------------------------------------------| > > > > >It's still unclear to me why the consumer would need request the >creation of a session to the producer, maybe I've missed something >during the last conf call. I would like to know what scenarios can not >be covered using a mechanism similar to the HTTP Cookies protocol: > >1) A client makes a request to a consumer >2) The consumer creates a Csession for the client >3) The consumer makes a request to a producer >4) The producer creates a Psession for the consumer request >5) The producer, together with the response, sends back the PsessionID >to the consumer >6) The consumer stores the PsessionID in the Csession >7) The consumer, together with the response, sends back the CsessionID >to the client >8) Future client requests to the consumer contain the CsessionID >9) Future consumer requests to the producer contain the PsessionID >associated to the CsessionID of the incoming client request >10) Sessions end/expire re-triggering the session acquisition steps on >subsequent requests > >In the absence of a consumer-producer session, the concurrency problem >-when producer receives concurrent consumer requests for different >portlets, where all the requests are to fulfill the same client request- >can be easily solved by having the consumer sending a transient common >ID with all the consumer-producer requests for the same client request. >This transient common ID would help the producer to manage the case when >portlets serving requests for the same client request ask for a session >to be created. Note that this transient common ID for consumer-producer >requests does not have to be same for different client-consumer >requests, although the protocol could use the same placeholder for the >transient common ID and for the consumer-producer session ID >(PsessionID). From the producer perspective, a transient common ID or a >consumer-producer session ID are no different except for the fact that >the later has been created by the producer, it could be used to store >transient local data associated with the session and it could have a >expiration. > >Regards. > >Alejandro > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > > > > > >---------------------------------------------------------------- >To subscribe or unsubscribe from this elist use the subscription >manager: <http://lists.oasis-open.org/ob/adm.pl> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC