tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [Catalina] Discussion -- Advanced Session Management Features
Date Tue, 01 Feb 2000 09:47:05 GMT
> > 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. 

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) 


View raw message