Using the SpaceDef object In the Java API, defining a space is done using the
defineSpace method of the
Metaspace object, which takes a
SpaceDefinition object as its sole parameter. In the C API, you define a space by calling the
tibasSpaceDef_Create() function.
If the space was already defined in the metaspace, then defineSpace compares the space definition that was passed to it as an argument with the space definition currently stored in the metaspace; if the definitions match then
defineSpace returns successfully, otherwise an error is thrown.
Using the admin object execute method A space can also be defined through the API by using the admin object’s
execute method to execute a
define Space admin language command.
You can get the space definition for a space that has been previously defined in the metaspace by using the Metaspace object’s
getSpaceDef method, which takes a space name as a parameters and returns either a copy of that space’s
SpaceDef object or throws an exception if no space of that name is currently defined in the metaspace.
You can delete a space’s space definition from a metaspace by invoking the dropSpace method of the
Metaspace object. This call will only succeed if there are no members to that space at the time this method is invoked. It is also possible to drop a space using the Admin tool.
The space definition is represented in the API by a SpaceDef object that is either created from scratch by invoking the
SpaceDef’s
create() method, or returned by the metaspace or space’s
getSpaceDef methods.
You can set or get a space’s distribution policy by using the SpaceDef object’s
setDistributionPolicy and
getDistributionPolicy respectively. The value of the distribution policy argument can be either
DISTRIBUTED (which is the default value) or
NON_DISTRIBUTED.
Replication in ActiveSpaces is performed in a distributed active-active manner: seeders both seed some tuples and replicate tuples assigned to other seeders. This means that the replication is distributed: rather than having a designated backup for each seeder that replicates all of the tuples that this seeder seeds, the tuples that it seeds are replicated by any of the other seeders.
A special replication degree of REPLICATE_ALL is also available. When it is specified for a space, all of the tuples in that space will be replicated by all the seeder members of the space. This allows the fastest possible performance for
get operations on the space, at the expense of scalability: each seeder member has a coherent copy of every single tuple in the space, and can therefore perform a read operation locally, using either its seeded or replicated view of the tuple.
The degree of replication can be set or gotten using the SpaceDef object’s
setReplicationCount or
getReplicationCount methods. The default value is 0, that is, no replication.
With host-aware replication, you can ensure that replicated data does not reside on the same system as the original data and therefore is not lost if that system goes down. Instead of increasing the replication degree to ensure that replicated data exists on other systems when more than one seeder resides on the same system, you can use host-aware replication instead.
ActiveSpaces groups all seeders with the same group_name together and their data will is replicated on seeders outside of that group.
One implication of the type of replication of a space on operations on that space is that asynchronous replication is more permissive in the sense that it allows operations that modify the data stored in a space even when the degree of replication can not be achieved at the time for lack of enough seeders. (Replication will be automatically achieved, however, as soon as enough seeders have joined the space.) Synchronous replication does not allow such operations. Asynchronous replication, then, is a
best effort quality of replication, while synchronous replication is a strict enforcement of the replication degree.
The type of replication for a space can be set or queried using the SpaceDef object’s
setSyncReplicated and
isSyncReplicated methods, respectively. Those methods take and return a boolean and the default value is false, that is,
asynchronous replication.
If a capacity is specified, then you must specify an eviction policy that is used to indicate the outcome of an operation that would result in an additional tuple being seeded by a seeder that is already at capacity. The two choices for the eviction policy are NONE, which means that the operation will fail with the appropriate exception being stored in the Result object, or
LRU, which means that the seeder will evict another tuple using the
Least Recently Used (LRU) eviction algorithm, where the least recently read or modified tuple will be evicted from the space.