"Diethelm Guallar, Gonzalo" wrote:
> 
> One of the reasons we have chosen a Java app server to base our
> development on is the advertised ability to add more instances of the
> app server when the load so requires, and that this balancing process
> is transparent to the programmer.  However, I have not really tried
> the experiment to see how this is done.  Therefore, I have a few
> questions, and would appreciate answers or pointers to information:
> 
> 1. Is the load balancing always done from the web server? I know the
>    web server could redirect all incoming requests to any of the app
>    servers, probably based on some idea of the load present on each
>    one.  Is this the "standard" way of doing things? Does Apache
>    support doing this? How do the commercial app servers (say,
>    WebLogic or WebSphere), which come with their own web server,
>    handle this? How does IIS handle it?
> 

The degree that this is supported likely varies between servlet
engines/app servers.  I believe this in the works for Tomcat/Apache, but
I do not know any details.

> 2. Would it be necessary for the web server to keep track of any
>    concept of "session", so that successive requests from a given
>    client are always handled to the same app server? If yes, who is
>    responsible for keeping the mapping between session and app server,
>    and how would the session be identified in an incoming request?
>    Would cookies be required?
> 
> 3. Does a Turbine-based servlet need to have any special code in order
>    to handle this load balancing mechanism, or is this totally
>    transparent for Turbine? If cookies are required, does Turbine know
>    when and how to set the proper cookie?
>

Sessions can be supported through cookies or url rewriting.  Turbine
uses cookies unless turned off and then uses url rewriting.  So the
session management should largely be transparent to the application
programmer.  Though scalability needs to be designed into the
application.  For an example look at IDBroker and how it uses a
transaction to prevent corruption if several IDBrokers are accessing the
same data.
 
> Thanks for any input,
> 
> --
> Gonzalo A. Diethelm
> [EMAIL PROTECTED]
> 
> ------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?:           [EMAIL PROTECTED]


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?:           [EMAIL PROTECTED]

Reply via email to