Mads Toftum wrote: > > On Fri, Jan 25, 2002 at 02:41:46PM +0100, Thierry Coopman wrote:
[snip] > > Now, what ahppens on a failure? > > - The server(s) that still exist can take over the ip address of the failing > > server > > - The LoadBalancing system detects it and doesn't use the machine any more. > > > > On the SSL side, since the server that fails over doesn't have the SSL > > session, the browser connecting to it fails to communicate. > > > That shouldn't be the case - if the session is either unavailable or has > expired on the server side, then the server and client will just negotiate > a new session. The problem is not that much the SSL session (as it can be renegotiated), but the 'business logic' session. Say you are in the middle of a transaction, like Credit Card auth, and the server fails, you need to make sure, that the transaction either: - rolls back entirely, or - is passed on the the next server that gets the connection. You can achieve that by using databases (clusters if you can afford it) or EJBs (Enterprise Java Beans) that have their own mechanism (using database persistence and other goodies) to ensure transaction integrity. [snip]
begin:vcard n:Nagy;Bal�zs tel;fax:720-294-0933 tel;work:303-523-5729 x-mozilla-html:FALSE url:http://www.thenewpush.com org:theNewPush, llc;Research & Development adr:;;601 16th Street #C-391;Golden;CO;80401;USA version:2.1 email;internet:[EMAIL PROTECTED] title:Managing Partner fn:Bal�zs Nagy end:vcard
