Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 50414 invoked from network); 3 Mar 2006 18:25:37 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 3 Mar 2006 18:25:37 -0000 Received: (qmail 77996 invoked by uid 500); 3 Mar 2006 18:26:21 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 77947 invoked by uid 500); 3 Mar 2006 18:26:21 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 77936 invoked by uid 99); 3 Mar 2006 18:26:21 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Mar 2006 10:26:21 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of james.strachan@gmail.com designates 64.233.166.177 as permitted sender) Received: from [64.233.166.177] (HELO pproxy.gmail.com) (64.233.166.177) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Mar 2006 10:26:20 -0800 Received: by pproxy.gmail.com with SMTP id d42so343667pyd for ; Fri, 03 Mar 2006 10:25:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=AP8rJRuT7gl6Ysnt9qu2PKMPOPmPKCJJzD+YZn4uKU+oVxGt9ZF1upjpuHwmDG+cPiTVSt2kW1REpMnMLuxmwzt7K7qZ7MGvV/dNZg3lPQ4vaT2ZGkqOlP7O2YgHVei9ho3Ps/4iEkKiAgTDRhtpjhDUXLyC7XVXSd7BLkA6yXE= Received: by 10.35.119.11 with SMTP id w11mr360934pym; Fri, 03 Mar 2006 10:25:59 -0800 (PST) Received: from ?192.168.0.2? ( [82.45.246.79]) by mx.gmail.com with ESMTP id d13sm404996pyd.2006.03.03.10.25.58; Fri, 03 Mar 2006 10:25:59 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) In-Reply-To: <8BD915E8-7E9B-423C-BAE0-30848C10DA49@iq80.com> References: <1F5F68F5-2E35-4AAF-B90B-072081D34FE7@gmail.com> <44042DE9.2080203@mortbay.com> <4406A4CA.7080501@mortbay.com> <8BD915E8-7E9B-423C-BAE0-30848C10DA49@iq80.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0CD29958-D067-41CA-BE1E-11859B60FF49@gmail.com> Content-Transfer-Encoding: 7bit From: James Strachan Subject: Re: Session API, was: heads up: initial contribution of a client API to session state management for OpenEJB, ServiceMix, Lingo and Tuscany Date: Fri, 3 Mar 2006 18:25:56 +0000 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.746.2) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 3 Mar 2006, at 02:17, Dain Sundstrom wrote: > On Mar 1, 2006, at 11:54 PM, Greg Wilkins wrote: >> Dain Sundstrom wrote: >>>> Now the above could be modelled with deep structure for the >>>> state associated with an ID, but not if all state for an ID >>>> has to be in one location. >>> >>> Having all of the state for a single session located on a single >>> machine is a design assumption. We felt that if you wanted to >>> let the >>> data be divided across several machines it was not a single session >>> session. >> >> But it is a common deployment to have the EJB on a different >> server to the web contexts ( I know it is not optimal ) >> >> If the session beans are going to be keyed under the same >> session id, then the one location does not work. >> >> If that's not a concern having the session ID map to >> a map of context to session is good for the web >> tier (aside from passivation concern). > > I think these are two different sessions. To me a session is a > bucket of data for a single client, and that bucket can't be > split. You do bring up a good point though. We need a way to make > sure that when you are in a session on one server and pass invoke > an ejb on another server that we do not use the same ID for the > sessions. Yeah. There's always the option that you have 2 completely separate Locator's which manage different physical systems so that the same session ID can be used in each without issues. So you either lump all the session data from web/JBI/SCA/EJB into one Session object (and so co-locate it all) or you split it into different logical Locators and locate it wherever you like. James ------- http://radio.weblogs.com/0112098/