The information provided here includes:
The clustered hash table APIs enable sharing and replicating of data between cluster nodes. The data is stored in nonpersistent storage. This means the data is retained only until the cluster node is no longer part of the clustered hash table. These APIs can only be used from a cluster node that is defined in the clustered hash table domain. The cluster node must be active in the cluster.
The clustered hash table server is started by using the Start Clustered Hash Table Server (STRCHTSVR) command. A cluster must be active on the node performing the start function. Using this command, the user defines the domain of the clustered hash table. A cluster resource group (CRG) (same name as clustered hash table server) is created to manage the domain of the clustered hash table.
There are two levels of security supported by a clustered hash table. One security level is associated with a clustered hash table server. This security is provided through the authorization list parameter on the STRCHTSVR command. This provides the ability to specify users that are allowed to start, end and connect to a clustered hash table server. For more details on the authorization list see the AUTL parameter on the STRCHTSVR command.
The second security level is provided on an entry stored in a clustered hash table. The authority access level is specified when an entry is stored in a clustered hash table. This provides the ability to restrict access to retrieving and updating an entry. For more details about the authority access level for an entry, see Store Clustered Hash Table Entry (QcstStoreCHTEntry) API.
First, a client must connect to the clustered hash table server using the Connect Clustered Hash Table (QcstConnectCHT) API. This establishes the communication infrastructure so clients can send requests to the clustered hash table server. A connection handle is returned to the client. This connection handle is required to be used on subsequent requests to the clustered hash table server. The client needs to connect from each job that is intending on communicating to the clustered hash table server.
Clients can disconnect from the clustered hash table server using the Disconnect Clustered Hash Table (QcstDisconnectCHT) API. The disconnect is necessary to cleanup the infrastructure established by the connection request. The disconnect is a local only request. It is recommended to use disconnect when done with the connection.
An entry is associated with a key and stored in a clustered hash table using the Store Clustered Hash Table Entry (QcstStoreCHTEntry) API. The key can be generated by using the Generate Clustered Hash Table Key (QcstGenerateCHTKey) API or the user can generate their own.
The storage for the clustered hash table is not persistent. Not persistent means the storage for the clustered hash table is only known to the server on the local node and only available until the clustered hash table server is ended. All requests to store entries are replicated to other nodes in the clustered hash table domain. When an entry is stored, a time to live value is specified. The entry can become expired, when the time to live value has expired. Expired entries will be removed when processing various functions. For example, when adding another cluster node to the domain of an existing clustered hash table server. The existing clustered hash table entries, if any, are replicated to the cluster hash table domain node being added. Expired entries are removed from the clustered hash table during this process.
An entry is retrieved from the hash table by key by using the Retrieve Clustered Hash Table Entry (QcstRetrieveCHTEntry) API. The retrieve request is only processed on the clustered hash table domain node requesting the function.
A list of all keys stored in a clustered hash table server can be obtained by using the List Clustered Hash Table Keys (QcstListCHTKeys) API. The list request is only processed on the clustered hash table domain node requesting the function.
The clustered hash table server is ended using the End Clustered Hash Table Server (ENDCHTSVR) command. The clustered hash table server will be ended on the cluster nodes specified.
The clustered hash table APIs have associated java classes. See ClusteredHashTable classes for details.
The clustered hash table APIs are:
[ Back to top | Cluster APIs | APIs by category ]