IBM®
Skip to main content
    Country/region [select]      Terms of use
 
 
    
     Home      Products      Services & solutions      Support & downloads      My account     
 
developerworks > My developerWorks >  Dashboard > WebSphere eXtreme Scale V6.1 User Guide > ... > Client-based JPA preload utility > Setting the availability of an ObjectGrid
developerWorks
Log In   View a printable version of the current page.
Overview Connect Spaces Forums Wikis
Setting the availability of an ObjectGrid
Added by saif.patel@us.ibm.com, last edited by Chris.D.Johnson on Jan 26, 2009  (view change)
Labels: 
(None)

Getting Started Examples Reference API documentation

See the WebSphere eXtreme Scale Wiki for links to eXtreme Scale Version 7.0 documentation.
If you log in with your developerWorks ID, you can leave comments and feedback for the development team.

The availability state of an ObjectGrid determines which requests an ObjectGrid is allowed to process at any particular time. There are four availability states:

  • ONLINE
  • QUIESCE
  • OFFLINE
  • PRELOAD

The default availability state for an ObjectGrid is ONLINE. An ONLINE ObjectGrid is able to process any requests from a typical ObjectGrid client. However, requests from a preload client are rejected while the ObjectGrid is ONLINE.

QUIESCE state is a transitional state. An ObjectGrid that is in QUIESCE will soon be in the OFFLINE state. While in QUIESCE, an ObjectGrid is allowed to process outstanding transactions. However, any new transactions will be rejected. An ObjectGrid can remain in QUIESCE for up to 30 seconds. After this time, the availability state will be moved to OFFLINE.

An ObjectGrid in the OFFLINE state will reject all transactions.

The PRELOAD state can be used to load data into an ObjectGrid from a preload client. While the ObjectGrid is in the PRELOAD state, only a preload client can commit transactions against the ObjectGrid. All other transactions will be rejected.

Setting the availability state

Use the StateManager to set the availability state of an ObjectGrid. Client ObjectGrids as well as server side ObjectGrids can have their availability state altered through the use of the StateManager. The following code demonstrates how to change the availability state of a client ObjectGrid.

ClientClusterContext client = ogManager.connect("localhost:2809", null, null);
ObjectGrid myObjectGrid = ogManager.getObjectGrid(client, "myObjectGrid");
StateManager stateManager = StateManagerFactory.getStateManager();
stateManager.setObjectGridState(AvailabilityState.OFFLINE, myObjectGrid);

Each shard of the ObjectGrid will transition to the desired state when the setObjectGridState method is called on the StateManager. When the method returns, all shards within the ObjectGrid should be in the proper state.

Use an ObjectGridEventListener to change the availability state of a server side ObjectGrid. It is recommended that the availability state of a server side ObjectGrid is altered only when the ObjectGrid has a single partition. If the ObjectGrid has multiple partitions, the shardActivated method will be called on each primary which results in superfluous calls to change the state of the ObjectGrid.

public class OGListener implements ObjectGridEventListener, ObjectGridEventGroup.ShardEvents {
    public void shardActivated(ObjectGrid grid) {        
            StateManager stateManager = StateManagerFactory.getStateManager();
            stateManager.setObjectGridState(AvailabilityState.PRELOAD, grid);        
    }
}

Since QUIESCE is a transitional state, the StateManager cannot be used to put an ObjectGrid into the QUIESCE state. An ObjectGrid will pass through this state on its way to the OFFLINE state.

Retrieving the availability state

Use the getObjectGridState method of the StateManager to retrieve the availability state of a particular ObjectGrid.

StateManager stateManager = StateManagerFactory.getStateManager();
AvailabilityState state = stateManager.getObjectGridState(inventoryGrid);

The getObjectGridState method chooses a random primary within the ObjectGrid and returns its AvailabilityState. Since all shards of an ObjectGrid should be in the same availability state or transitioning to the same availability state, this method provides an acceptable result for the current availability state of the ObjectGrid.

Appropriate availability states for various requests

A request will be rejected if an ObjectGrid is not in the appropriate availability state to support that request. An AvailabilityException is thrown whenever a request is rejected.

The initialState attribute

The initialState attribute can be used on an ObjectGrid to indicate its startup state. Normally, when an ObjectGrid completes initialization, it is available for routing. The state can later be changed to prevent traffic from routing to an ObjectGrid (see: Setting the availability of an ObjectGrid). If the ObjectGrid needs to be initialized, but not immediately available, you can use the initialState attribute.

The initialState attribute is set on the ObjectGrid configuration XML file. The default state is ONLINE. Valid values include:

  • ONLINE (default)
  • PRELOAD
  • OFFLINE

See the AvailabilityState API documentation for more information.

If initialState is set on an ObjectGrid, the state must be explicitly set back to online or the ObjectGrid will remain unavailable. It will throw AvailabilityExceptions.

Using the initialState attribute for preloading

If the ObjectGrid will be preloaded with data, there can be a window between when the ObjectGrid is available and switching to a preload state to block client traffic. To close this window, the initial state on an ObjectGrid can be set to PRELOAD. The ObjectGrid will still complete all the necessary initialization, but it will block traffic until the state changes and allows the preload to occur.

The PRELOAD and OFFLINE states both block traffic, but you must use the PRELOAD state if you want to initiate a preload.

Failover and balancing behavior

If a replica is promoted to a primary, it will not use the initialState setting. If the primary is moved for a rebalance, the initialState setting will not be used because the data will be copied to the new primary location before the move is completed. If replication is not configured, then the primary will go into the initialState if failover occurs and a new primary must be placed.

Additional information

Wiki Disclaimer and License
© Copyright IBM Corporation 2007,2009. All Rights Reserved.


 
    About IBM Privacy Contact