--- Carlos Gaston Alvarez <[EMAIL PROTECTED]>
> We have an instance of the database to store the
> sessions.
What does "the database" mean? If we're persisting
the sessions to a real RDBMS, then that's a serious
performance hit above and beyond just having to
serialize the session whenever it's accessed. Not to
mention that the user would have to add DB config info
into the TC config.
An alternate implementation would be to maintain this
data in memory using a similar "table-like" object.
When sessions are created/modified, you broadcast the
changes on a multicast address. All other interested
servlet engines can pick up this change and replicate
it locally. This could conceivably be done
using the Servlet 2.3 HttpSessionAttributeListener
interface, and could also provide transparent failover
for distributed sessions.
Persistence to a database really only makes sense if
you're dealing with MANY sessions (or perhaps many
long-lived sessions) and you need an
activate/passivate behavior to conserve memory.
> Session creation is a litle tricky because be should
> get sure that no other
> virtual machine is trying to create the same session
> (for the same user) and
> if so syncronize them.
Well, there's really not much you can do about this.
This situation would occur if the same browser
accessed two different servlets simultaneously. For
cookie-based sessions, the browser would get the
session id for whichever servlet sent the cookie last.
For url-rewriting based sessions, you'd have two
different sessions started. I think this situation is
sufficiently rare to not worry about.
> On every request:
>
> - get the lock sessionLocker (check if the locker is
> 0, if it is we take it;
> if it is not we wait until the locker is 0 try
> again). [sessionLocker = me]
> - check if it is the same sessionVersion.
> - if yes just use the session at memory. (why
> unserilize it if we can have
> them in memory?).
> - if not get the session of the database
> (sessionStream) and unserialize it.
>
> * now the user request runs as normal, until it is
> finished when ..
>
> - sessionVersion++
> - sessionStream gets updated.
> - sessionLocker = 0
>
> There are other optimizations but I will not discuss
> them now not to make a
> mess.
A simple optimization: you mention above "On every
request"... but really it is only "On every request
that calls getSession" because if the servlet never
accesses the session, we don't need to worry about it
changing. So the "pre-request" stuff you mention
above should really be done when getSession is called,
and the "post-request" stuff should be done after the
request is completed, but only if getSession was
called during the request.
All of this points to a solution presented much
earlier in this thread - that any time the session is
accessed we have to consider it dirty. The more I
think about this the more it makes sense - you
*really* don't want the developer to have to keep
track of whether or not the session is dirty.
Finally, this is a lot of extra processing to do if
the web app is only run on a single machine. Perhaps
a directive in the server.xml could indicate whether
sessions should be shared/synchronized across multiple
servlet engines or not.
- osama.
__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
