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
