Inprise support the fail over safety of

Take a break and read the clustering whitepaper on this site so that you get
a better understanding of this area:

http://www.inprise.com/appserver/papers/

Exracted from IAS 4.0 FAQ
============================================================================
================================
Failover is supported by leveraging the Naming Service and the osagent. We
support failover of all types of EJBs. To summarize the
behavior:

1) Stateless Session Beans. If you run multiple containers (e.g., VMs) with
the same Stateless SB, they will act as fail-over replicas
of each other. So call (1) to a Stateless SB will go to VM 1. If VM 1 shuts
down, and the SB is installed in VM 2, then call 2 will go
to VM 2. The client will be unaware of the fail-over. Since the beans are
stateless, this is correct behavior.

2) Entity Beans. From the Container standpoint, Entity Beans are similar to
Stateless Session Beans, except that before being able
to use a replica entity, it needs to be loaded in. The current transaction
will fail, as it should. Both the resource and the
synchronization objects associated with the original (failed) entity in VM 1
will be unavailable, and the transaction manager,
presuming rollback (as per the OTS/JTS specification) will roll back the
current transaction. However, subsequent transactions
will simply fail-over to use the replica entity in VM 2, and will continue
correctly.

3) Stateful Session Beans. Stateful SB are passivated into a JDatastore
database, which is available via an IDL interface. This
Session Storage service can either run in process, or out of process. If run
out of process, multiple Containers can share a single
Session Storage service. So, let's assume we have two Containers (one in VM
1, and one in VM 2) running replicated Stateful
Session Beans, and the Session Storage service running in VM 3. Let's say a
client creates a shopping cart (a Stateful SB) in VM 1.
The shopping cart will be automatically passivated every 5 seconds (a
tuneable parameter). Then let's say that the client puts a
book into the shopping cart, and then thinks for a while. The shopping cart
will be stored persistently within 5 seconds in the
Session Storage. Now, lets say VM 1 crashes. The shopping cart EJBObject
will automatically fail-over to VM 2. This container will
see that it doesn't have the state for the user's shopping cart activated,
and it will load the state from the storage server (VM 3).
The client will now continue using the shopping cart with its contents
intact.

William Louth

> -----Original Message-----
> From: dan benanav [SMTP:[EMAIL PROTECTED]]
> Sent: Tuesday, February 29, 2000 11:11 AM
> To:   [EMAIL PROTECTED]
> Subject:      Clustering with automatic failover of entity beans?
> (Provided by any vendors?)
>
> Do any vendors provide for clustering with automatic failover of entity
> beans?  I know that WLS does not.  How about Gemstone?  If not is there
> a reason why it is not possible?
>
> It seems to me that EJB servers should be capable of automatic failover
> of entity beans and without that it will be difficult to write a
> clustered based application.
>
> dan
>
> ==========================================================================
> =
> 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".


***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************

===========================================================================
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".

Reply via email to