>I'm very interested in this subject myself.
>
>Let's see:
>
>1. Servlets/JSP: see
>http://java.apache.org/jserv/howto.load-balancing.html
>To summarize: you can get load-balancing with Apache servlets, but once a
>session is established,
>failover cannot maintain session state.
>"The session is broken if a request is redirected to another JServ. The
>existing one is considered invalid, as sessions can not travel across the
>network (not in Servlet API specs). "
>
>You could get state failover with servlets if the Session interface is
>implemented so that session
>data is stored in a repository that's shared by several nodes. For instance
>it could be stored in
>a database instead of in the servlet's own JVM. In this case any node could
>provide state to any servlet.
>I have implemented something like this to store session state for servlets
>in Oracle.
>
>2. EJB:
>HTTP load-balancing is a lot easier than RMI/IIOP load-balancing for
>obvious
>reasons.
>EJB clients keep a remote reference to some server component.
>
>+ load-balancing getting a reference to an EB: this can be donde with
>replicated JNDI directory servers
>that provide remote references to components running in one or several
>nodes.
>See www.objectspace.com VAS for an example of this technique.
>
>+ load-balancing remote method invocations: this could be done with some
>kind of multicast
>mechanism, TIBCO-like maybe, but the problem is state replication among the
>candidate nodes.
>Usually once the client gets a remote reference it will use a single
>component without load balancing
>until the component fails and failover is considered.
>+ failover of stateless SBs: it's a question of the remote reference being
>able to reconnect to a
>different node. No state needs to be preserved. I think WebLogic has this
>feature.
>
>+ failover of stateful SBs: same as servlets session state failover with
>the
>added problem of
>reconnecting the remote reference. NetDynamics has(/had? is ND still
>alive?) Persistent Session (PS)
>for this. The problem with ND is EJB-compatibility, of course.
>
>+ failover of entity-beans: this should be no problem the way EBs are
>defined in the spec.
>The issue here is to be able to run several instances of the "same" EB in
>different nodes.
>I understand that each tx commited should update the state of all instances
>in every load-balanced
>node, or then the state of every instance should be refreshed at the start
>of every new tx.
>I'm very interested in other people's views on this subject.
>Regards
>
> Javier Borrajo
> www.tis.es
>
<vendor>
Weblogic does provide fault load balance/tolerance/replication mechanisms.
You can have a cluster of weblogic servers with any of these configurations:
* Servlet clustering provides load balancing or load balancing plus
failover for servlet sessions. It will provide failover at the point in a
session lifetime at which it is committed to disk, that is, when the session
is persistified. A session that is in-memory only cannot be failed over.
* Object clustering is a likely configuration for load balancing and
failover of services across a set of WebLogic Servers. Each server handles
client communications as well as the execution of requests. The three-tier
cluster also provides the ability to "route" applet requests between the
server with
which the applet is communicating and the server hosting the service object
(impl) that the applet wants to use.
* mixed objects and servlets, the most usual conf.
I am not sure how it is archieved, although I have read it uses a multicast
protocol that replicates states among different machines (there is a
configurable weblogic.cluster.multicastTTL property).
I do not work for BEA. :-) But I am using weblogic. I have also used BEA's
M3 ORB and it can handle migration, replication, load balancing and fault
tolerance for CORBA objects in a rather transparent way.
</vendor>
--
Oscar Aza�on Esteire
IT Engineer - Oviedo, Spain
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
