----- Original Message -----
From: "GOMEZ Henri" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, November 13, 2001 9:15 AM
Subject: RE: Tomcat: Distributed Session Management revisited

... stuff deleted ...

| >Notice also, in my concept, there are no delays built into the
| >architecture
| >(other than the natural delays caused by sending data over the
| >network).
| >The session server can simply respond to callers on-demand.
|
| I've discussed some time ago about this subject and adding the session
| stuff in the Connector, maybe webapp/warp could be tuned for this
| purpose.

Agreed, this distributed session management feature, however it winds
up being implemented, would certainly NOT be the default behavior
provided by Tomcat and would require mucking around with server.xml
in order to make this work.

|
| It's clear that the persistance and replication of session data is
| needed for HA systems, and many solves it by using the EJB backend
| as repository, WebSphere for example. In some case it appears also

HA is only part of the picture. What I'm wanting to achieve is seamless
scaling by adding more servers.

Also, while EJB could be used for this purpose, it adds a dependancy
that I don't wish to add.

| very expensive to try to add automatically this persistance
| (maybe something to be added to server.xml , some webapps could
| live without session data even, in a soft restart mode).

Again this could depend on the 'SessionManager' object configured for
the given context/web-app in server.xml.

|
| There is also the problem of finding a fast and portable network
| protocol (multicast may not run on all system, Broadcast UDP need recovery
| code).
|

RMI is certainly as portable a protocol as you can hope to find (at least
in our Java context). Is it fast enough? I would argue that it is fast
enough
that J2EE is built entirely upon it. It must therefore be fast enough for
us. It also has the advantage of simplicity. I'm a big fan of simplicity,
even
if I can't sew.



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to