> > 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.

How? The API has no way to "flag" what changed.
You call getAttribute("shopingC"), you get a ShopingC object. 
You call setXXX method. Then what? How will tomcat know that the 
object is "dirty" ? 

I have some OO database experience, it's one of the most complex things
even if you have a full API to play with ( and all you have is  
get/setAttribute() ) ! 

Sorry, I don't understand how  you think this will work...


> 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).

But how ????

That's the problem, fail-over is very complex and can't be solved with
just get/setAttribute() and serializable objects.

You can have partial fail-over ( if a server fail _some_ objects _might_
be available on the fail-over server ), but you can't have a guarantee
that all are. 
It's imposible even with real databases - a Transaction can
fail and be rolled back, you should have code to deal with that - your
software will have no way to know the setAttribute() wasn't replicated. 



> 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.

Ok, sharing what? How can a user specify that an object shouldn't be
shared between servers? ( like a big GIF that is cached for speed - one of
the biggest use for Session is to keep pools or cached objects, to avoid
reading them from file system/network). 

BTW, the API have no way to specify "this object is a cache object, don't
share it". 

It nice to win converts, but it's important how - not by letting them
think that we support "fail-safe" when we don't, or that it is possible to
do that when it isn't ( AFAIK ).  


> 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.

The problem is that there is no _real_ solution ! You get partial
fail-over, and IMHO it's worse than no fail-over at all, because you'll
never know if you have a full recovery and all your session objects are
preserved or not. 

Costin