On 12/29/00 6:35 PM, "Jon Stevens" <[EMAIL PROTECTED]> wrote:
> If the server crashes, then you are screwed either way.
>
> If you are live, then serializing/deserializing the sessions for each and
> every request could be a major slowdown (even with this code). This is why
> there still isn't a good session server available. :-)
Database folks will argue that the best session server would have a database
as a back end. After all -- databases have to solve problems of both speed
and safety as well. Of course going through SQL and an access API nukes out
some advantage. :) But without a lot of work (of which this looks like a
pretty damn good start), they are most likely right.
When session support was put into the servlet api, this was one of the
things that was debated. There's really no good answer except: use sessions
for data you don't mind getting splatted in a pinch, or that you won't do
anything more than annoy if it goes splat (loosing a shopping cart even is
annoying, but not totally reprehensible as long as you have 99.9% updtime).
Data that has to be preserved has to go into a database or an EJB. Anything
involving money for sure. :)
--
James Duncan Davidson [EMAIL PROTECTED]
!try; do()
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
