tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brill Pappin" <brill.pap...@jmonkey.com>
Subject Re: [Catalina] Discussion -- Advanced Session Management Features
Date Tue, 01 Feb 2000 13:18:18 GMT

----- Original Message -----
From: <costin@eng.sun.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Tuesday, February 01, 2000 9:47 AM
Subject: Re: [Catalina] Discussion -- Advanced Session Management Features


> > > One possible reason you might want to copy the session information
anyway is to
> > > provide some sort of fail-over service if a server dies.  It may be
better to
> > > persist the data to the persistent store after any changes, and then
share the
> > > persistent store between the JVMs, so a different server can "pick up"
that
> > > session and continue processing it.  You still need to "write" the
session
> > > information on some regular basis, but you only need to "read" it when
the
> > > session is actually migrated.  Does that sound reasonable?
>
> Question: do you have sync or background write ? That mean, if
> shopingChart.deleteItem() is called, does it wait for the write to happen
> or the write will happen in background?
>
> First choice is wrong - every time you change a session object you'll have
> to do a write on disk. It is also wrong because you have no way to guess
> if the object was changed or not. And you might have many "cache" or
> "pool" objects in the session - you don't want to have all objects saved
> ( but how can you specify which are important ?)
>
> Second choice is worse - if the write is in background, the servlet will
> think it changed the object, will return the page confirming that, and the
> user will click "buy". Now the server crashes, the new request is
> redirected to the "fail-recovery" server - with no idea that the user
> just removed 1/2 of the items.

Both will work, but I agree that writing every time the object changes is a
wast of resource... however, your granularity then becomes *very* important.
Also, there is no reason that a session couldn't flag that it had changed...
If your working this way, a combination would be best I think.

> What's wrong is that you advertise "fail-over" - and the servlet authors
> might believe you, and rely on this ( why do I need a complex transaction
> when tomcat does provide fail-over ? )

> Again, I don't think the intention of session is to provide a real
> storage, you can use it to cache objects ( like jdbc  Connections), or for
> non-critical tasks ( if an object is lost, it shouldn't affect your
> application too much - just create another one ). For anything else use
> transactions and real databases ( or serialization, or any "real" storage)

No matter what you do, I believe that managing the "fail-over" in the server
will still be the most efficient way to do it (as opposed to using an
outside system).

For me, the issue is not so much fail-over but session sharing between
distinct servers. However, fail-over is *almost* automatically taken care
of, if you do have more than one server, and all the servers in the pool are
"equal". Now, that doesn't mean that I would advertise Tomcat as
"fail-safe", but giving it the ability to run well, and do it with minimal
configuration is very important, and will win converts.

I think that Tomcat should be as clean and foolproof as possible, if an
administrator then wants to implement their own (real?) system, there is
nothing stopping that from happening.


- Brill Pappin
  www.jmonkey.com

  "The sooner you fall behind,
  the more time you will have
  to catch up."


Mime
View raw message