Chapter 4 Load Balancing, Failover, and Component Availability

Automatic failover

You can use Jaguar Manager to mark selected components to support transparent automatic failover. If a client has an object reference for a component on a server that is a member of a cluster, the client's object reference will provide transparent failover, unless all the servers in the cluster fail.

   To avoid a single point of failure for a cluster, set the com.sybase.jaguar.cluster.startup cluster property to check_servers. See "Cluster start-up options" for more information.

Automatic failover is not the default for Jaguar components. When a client is using a component that does not support automatic failover, and the server hosting that component fails, the client must create a new instance of that component to recover from the failure (which typically presents itself as a CORBA COMM_FAILURE system exception). However, the client does not need to create a new session, since the SessionManager::Session object supports automatic failover. The SessionManager::Session object is used implicitly by the PowerBuilder connection object and by the Jaguar COM (ActiveX) proxy.

To set automatic failover for a component from Jaguar Manager:

1. Locate and highlight the component you want to set.
   
   
2. Select File | Component Properties.
   
   
3. Select the Transactions tab.
   
   
4. Select the Automatic demarcation/deactivation check box and the Autofailover check box.
   
   
5. Click OK.
   
   

Component guidelines

The following guidelines may be useful when you are writing components that support automatic failover.

The component should not retain conversational state in server memory (component instance variables), since the conversational state cannot be restored when a remote method call fails over from one server to another.

The following example shows why this would not work:

1. The client calls method A on component C on Server1. Method A retains some state in the instance in Server1's memory.
2. The client calls method B on the same component. Server1 has failed, so the client transparently fails over to Server2 and calls method B on a newly instantiated instance of component B in Server2. Since method A has not been called on this instance, it does not hold the saved state.

If you must save state between calls, consider saving it in a database. For example, in an Internet shopping application, a "shopping cart" might be represented by a database entity, and every method call on the ShoppingCart component can save the appropriate changes to the database.

In other cases, you might want to code the client to use IDL structure and sequence types to pass a list of values to a single component method, instead of passing each value in a separate call and having the component attempt to collect the list of values using conversational state. This approach also reduces network traffic, and can greatly improve response times.

Duplicate database inserts or updates can result from the use of automatic failover, as in the following example:

1. The client calls method insertStuff on component C on Server1.
2. The insertStuff method inserts a record into a database.
3. The transaction is committed.
4. The server crashes before sending the reply message over the network to the client.
5. The client transparently fails over, and calls method insertStuff on a new instance of component C on Server2.
6. The insertStuff method inserts a new (duplicate) record into the database.
   Everything works this time, but we now have a duplicate record in the database.
   

A simple design approach can help avoid such problems. Add a method to component C to generate a new ID for insertion: for example, newStuffId:

1. The client calls newStuffId to get a new unique ID. If you do not permit gaps in the ID numbering sequence, you cannot use this approach.
2. The client then calls insertStuff, passing the StuffId as a parameter.
3. insertStuff verifies that a record for that StuffId has already been inserted (or the database insert fails if StuffId is a unique key in the database).
   Although insertStuff has been called twice, only one database change has been made.
   

A component that supports automatic failover can use other components or resources that do not directly support automatic failover.

Copyright © 2000 Sybase, Inc. All rights reserved.