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