Re: JDBC session store, release date projections, etc

[Bip Thelin]

 Dunlop, Aaron wrote:
 
 [...]
 First: We will need to cluster application servers in front of a central database.
 We want the ability to add and remove servers from that farm in real-time,
  without disturbing ongoing sessions. That either means storing sessions remotely
 in the central DB, or migrating sessions from one machine to another.
 We'd like to avoid being forced into using session-affinity for load balancing,
  since in our environment, that would likely result in significantly unbalanced 
loads.

There is some effort going on to provide Clustering ability for TC4, currently you can
use it for in memory replication of sessions, however this feature is considered 
highly experimental.

 So that probably means we need JDBC session store. Correct? And if so, what (in your 
opinions)
 is the current state of JDBC Session Store? (Also - am I correct that it's only 
available under
 Tomcat 4.0? Will it eventually also be available under the 3.x series?)

When it comes to storing sessions you can use either FileStore or JDBCStore, I would 
say that
both are considered medium rare.

..bip

Re: JDBC session store, release date projections, etc

[cmanolache]

On Thu, 24 May 2001, Dunlop, Aaron wrote:

 First: We will need to cluster application servers in front of a central
 database. We want the ability to add and remove servers from that farm in
 real-time, without disturbing ongoing sessions. That either means storing
 ...
 So that probably means we need JDBC session store. Correct? And if so, what
 (in your opinions) is the current state of JDBC Session Store? (Also - am I
 correct that it's only available under Tomcat 4.0? Will it eventually also
 be available under the 3.x series?)

It shouldn't be difficult to port it to 3.x, but I don't think this is a
priority. I also don't think such a thing should be included in 3.x - if
anyone does the port, it should be released as a separate module. We are
trying hard to keep 3.x to the essential level and move any
non-essential features outside of the standard release.


My personal opinion is that such code shouldn't even be part of the
servlet container - but implmented as a user-space util. I know most
people have a different opinion.

If you want your data stored in a JDBC database - it's far better to do it
yourself, and treat the tomcat session as a simple cache. You'll have far
more flexibility, the code will run on any servlet container, you'll have
access to a more powerfull API ( like transactions ).

There is no way to insure consistency ( or acid) using only the session
API - saving an object in the session and hoping the container will save
it is far worse than using an API that will also tell you if the operation
was successfully executed ( and no container can guarantee the save was
successfull - there is no way to pass this information in the servlet
api).


Of course, I am probably wrong - since most people seem to believe the
container can hide such a complex problem behind the simple session API.


Costin