tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James House <james.ho...@partnet.com>
Subject Re: Distributed Session Server
Date Thu, 29 Jun 2000 16:34:33 GMT

>The other issue is doing it within the Servlet Spec. This is something that
>gives the guidance to do it. It is just that the actual implementations have
>always been lacking. I want to make this session stuff as transparent and
>"spec" compliant as possible for the engineers. In Turbine, we accomplished
>this goal with data.getUser().get/setTemp() and data.getUser().get/setPerm()
>which allow you to essentially stuff things into a Hashtable. The setPerm()
>hashtable is something that is serialized into a database using the
>HttpSessionListenEvent (or whatever that interface is) because the User
>object is in the HttpSession object. It is totally transparent to the end
>developer that this stuff actually gets serialized/persisted for you. Very
>cool in my opinion. The get/setTemp() is just lost when the User object in
>the Session is lost.

I'm with Costin: I'm not sure that making it transparent is the best goal.
(I do agree it would be a big plus).  But to add lots of cool features, you
need to add ways to control them.


>Now, the problem in the above diagram is that if the SessionServer dies on
>us, we need to have some sort of backup procedure. HSessionComm should be
>able to deal gracefully with that by switching to another SessionServer.
>
>App/Engine 1           App/Engine 2
>     |                       |
>   HSessionComm         HSessionComm
>         |                   |
>         |                   |
>     ------------------      ------------------
>     | SessionServer  |------| SessionServer  |
>     ------------------      ------------------
>                   |         /
>                  -------------
>                  | Storage   |
>                  -------------
>
>As you can see, the two SessionServers are able to communicate with each
>other.

This is VERY similar to what I've designed a few different times/ways,
and have come VERY close to building... however, it still didn't totally
meet our needs, so I haven't invested the time.

I'd personally be very interested in helping build something like this
as an open source project.

I think it should be built so that:

* It can be used by any servlet engine.
* It has "plugable" persistent mechanisms (i.e. filesystem, OODB, RDBMS)
* User can specify persistence strategies (persist entire session every 
request,
   re-persist only changed objects, persist nothing, read all session data 
every
   request, read only certain session data every request, etc. etc.)
* Clustering of session servers (1 to N)
* User can specify "locking" strategies. (to work around concurrency issues -
   this is actually a really big issue for my company - the state of a session
   is extremely complex - because users of the site will very comonly open
   two or three browser windows and do very different things in each at the
   same time - and they all share the same session)
* User can specify "transactionality" strategies.
* Depending on choices of strategies, things could work fairly transparently,
   or could require specific coding... but the idea is that the developer gets
   to choose how to use it.

I've had lots of ideas on all of these things and would love to work
with a others desiring to build such a beast.

James



Mime
View raw message