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? > >> >>>> - 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 >>
