Re: [Catalina] Discussion -- Advanced Session Management Features

[co...@eng.sun.com]

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

Costin

Re: [Catalina] Discussion -- Advanced Session Management Features

[Brill Pappin <br...@jmonkey.com>]

I agree with you. I think the area we don't agree on, is what "to advanced"
means... but no matter, I'm sure we'll get all the useful idea
implemented... at this point, I'd just like to get on with it :)

- Brill Pappin
  www.jmonkey.com


----- Original Message -----
From: Costin Manolache <Co...@eng.sun.com>
To: <to...@jakarta.apache.org>
Sent: Tuesday, February 01, 2000 9:40 PM
Subject: Re: [Catalina] Discussion -- Advanced Session Management Features


> > I think the idea of a session is getting way out of hand here. A session
is
> > designed to hold simple data between browser requests. It is not
designed to
> > be a chache for large ampounts of data, or to contain the main component
in
> > an application. In a properly built system, the session is only used for
> > state, id, or other temporary values.
>
> "Advanced Session Management" is very important - for example to allow
> efficient memory usage, to allow sessions to survive a server reload, etc.
>
> I am just against "fail-over" or "too" advanced management, I think there
> are better tools for that ( databases, J2EE, or any transaction system).
> Implementing fail-over without transactions is difficult.
>
>
> Costin
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>

Re: [Catalina] Discussion -- Advanced Session Management Features

[Costin Manolache <Co...@eng.sun.com>]

> I think the idea of a session is getting way out of hand here. A session is
> designed to hold simple data between browser requests. It is not designed to
> be a chache for large ampounts of data, or to contain the main component in
> an application. In a properly built system, the session is only used for
> state, id, or other temporary values.

"Advanced Session Management" is very important - for example to allow
efficient memory usage, to allow sessions to survive a server reload, etc.

I am just against "fail-over" or "too" advanced management, I think there
are better tools for that ( databases, J2EE, or any transaction system).
Implementing fail-over without transactions is difficult.


Costin

Re: [Catalina] Discussion -- Advanced Session Management Features

[Brill Pappin <br...@jmonkey.com>]

Ok, I can see that temper is beginning to play a part in this thread. Could
someone summerize the requests (or add it to the spec)? I would be happy to
work on a portion of this if someone closer to the project wants to
delagate, or review for addition.

I think the idea of a session is getting way out of hand here. A session is
designed to hold simple data between browser requests. It is not designed to
be a chache for large ampounts of data, or to contain the main component in
an application. In a properly built system, the session is only used for
state, id, or other temporary values.

Though the servlet 2.2 spec doesn't say the above exactly, it does say that
serialization can be enforced on data within a session (see section: 7.7.2
in the Servlet 2.2 Spec).

- Brill Pappin
  www.jmonkey.com

Re: [Catalina] Discussion -- Advanced Session Management Features

[co...@eng.sun.com]

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

Re: [Catalina] Discussion -- Advanced Session Management Features

[Brill Pappin <br...@jmonkey.com>]

----- Original Message -----
From: <co...@eng.sun.com>
To: <to...@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."

Re: [Catalina] Discussion -- Advanced Session Management Features

[Assaf Arkin <ar...@exoffice.com>]

+1

And that's the last I'm going to say on this subject, promise.

arkin


> 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)
> 
> Costin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org

-- 
----------------------------------------------------------------------
Assaf Arkin                                           www.exoffice.com
CTO, Exoffice Technologies, Inc.                        www.exolab.org