Hi Jeff, On Wednesday, July 12, 2006, at 11:25AM, Jeff Genender <[EMAIL PROTECTED]> wrote:
> > >Bill Dudney wrote: >> Hi Dain, >> >> Thanks for the response, my response inline... >> >> (for anyone getting this twice, sorry I sent to both the incubator list >> and the old codehaus list) >> >> On Jul 10, 2006, at 10:20 PM, Dain Sundstrom wrote: >> >>> On Jul 10, 2006, at 8:43 PM, Bill Dudney wrote: >>> >>>> >>>>> The biggest TODO as far as session id would be to decide on what it >>>>> is. Namely, is it: >>>>> >>>> >>>> I'm still a newbie to the code base so I don't fully understand all >>>> the ramifications of the following choices but here are some of my >>>> thoughts from the session-api/caching impl perspective. >>>> >>>> I have a short write up of the current caching impl that can be found >>>> here; >>>> >>>> http://cwiki.apache.org/GMOxDEV/caching.html >>>> >>>> which drives many of my comments below. >>>> >>>> Basically, the finer grained the session-id the less contention there >>>> would be in the cache. >>> >>> Say what? Contention is caused when two+ parties attempt to access >>> the same data. IMO you want to choose the biggest grain size where >>> you will have little or no contention, because small grain size comes >>> at the cost of extra book keeping and locking. In our case, since the >>> data in the session is for a single client and is naturally >>> partitioned there will never be any contention by definition. >> >> I am thinking along the lines of two threads trying to read/write to the >> same key at the same time. Perhaps we are thinking about the same thing? >> The reason smaller is better in the current impl is that the locking >> happens on a per key basis. So if the sessionid were on a per client VM >> (lets say web app vm for example) level each 'user' or 'client' in the >> client vm would be locking the whole session from other 'users' within >> that VM while the session is being updated. >> >> With a smaller scope of the session id (i.e. one session id per remote >> ejb proxy for example) there would be less chance of two clients trying >> to read/write from the same locked resource. >> >> What don't I get? > >I am agreeing with Dain here...how would there even be a possibility of >2 parties hitting the same key...how would you have 2 threads trying ot >read/write to the same key at the same time? How can you have more than >1 user per session? > If the seesion id is tied to the client vm, i.e. the web vm then there is one session id per web tier vm (which in all likelyhood has many many users). >> >>> >>>>> - one session id per client vm >>>> >>>> With the current caching impl outlined above this solution would >>>> cause lots of contention. Each write would cause the whole client-vm >>>> part of the cache to be locked (i.e. the lock is on the key). >>> >>> Assuming that a client vm has more than one user. In general, this is >>> a good strategy for J2ee app clients but a poor choice for multi user >>> vms (web apps). >>> >>>>> - one session id per client connection >>>>> - one session id per login (security scoped) >>>>> - one session id per remote ejb proxy >>>> >>>> This would cause the least amt of contention since the session-id >>>> would lock only the data for the particular remote object. >>>> >>>>> >>>>> Or some other option i haven't considered. >>>>> >>>>> Thoughts? >>>>> >>>>> The per connection option seems attractive though it would require >>>>> some code change as we don't currently support a keep-alive concept. >>>>> >>>> >>>> I'd prefer to keep the initial code changes to a minimum just to get >>>> something working. >>> >>> me 2 :) >>> >>> -dain >>> >>> --------------------------------------------------------------------- >>> To unsubscribe from this list please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> > >
