A metaspace is a virtual entity that contains spaces, which are containers that store the data used by applications.
A metaspace is:
• An instance of a cluster of application processes. The processes are usually deployed on multiple hosts interconnected by a network where ActiveSpaces is installed (ActiveSpaces applications can also be installed on a standalone host).
The metaspace represents the cluster of hosts and processes that share the same metaspace name and set of discovery transport attributes. The hosts and processes in a metaspace work together by joining the same tuple spaces.
• An administrative container for a set of spaces. A metaspace can contain
−System spaces—Spaces defined by ActiveSpaces.
−User spaces—User-defined spaces.
To use ActiveSpaces, your application must first connect to a metaspace. When it is connected to a metaspace, your application can define and make use of any number of spaces.
Multiple independent metaspaces can be deployed over a single network of hosts, each with a different set of members and spaces, and each identified by a name and a set of network transport attributes. Applications can connect to more than one metaspace at a time, but can only have a single connection for each metaspace.
A metaspace is a virtual entity: it is created when the first process connects to it, and disappears when the last process disconnects from it. The metaspace grows or shrinks automatically as members connect to it and disconnect from it.
Initially, a metaspace contains only system spaces. As users create spaces in the metaspace, the definition of those spaces (along with other administrative data) is stored in system spaces.
If you implement the ActiveSpaces data persistence feature, you can persist data to local storage. However, space and field definitions are not persisted in existing spaces after the last metaspace disconnects from it.
If the metaspace is configured to make use of multicast for discovery, there is no need to provide a list of IP addresses of core metaspace members or to connect to it.
Multiple metaspaces may exist at the same time, each one containing a completely independent set of spaces. This means, for example, that changes to a space called clients in a metaspace named Dev have no impact on a space named clients in a metaspace named Prod. Since no single application can connect to two different metaspaces using the same metaspace name, metaspaces should always use different names.
A metaspace is:
• An instance of a cluster of application processes. The processes are usually deployed on multiple hosts interconnected by a network where ActiveSpaces is installed (ActiveSpaces applications can also be installed on a standalone host).
The metaspace represents the cluster of hosts and processes that share the same metaspace name and set of discovery transport attributes. The hosts and processes in a metaspace work together by joining the same tuple spaces.
• An administrative container for a set of spaces. A metaspace can contain
−System spaces—Spaces defined by ActiveSpaces.
−User spaces—User-defined spaces.
To use ActiveSpaces, your application must first connect to a metaspace. When it is connected to a metaspace, your application can define and make use of any number of spaces.
Multiple independent metaspaces can be deployed over a single network of hosts, each with a different set of members and spaces, and each identified by a name and a set of network transport attributes. Applications can connect to more than one metaspace at a time, but can only have a single connection for each metaspace.
A metaspace is a virtual entity: it is created when the first process connects to it, and disappears when the last process disconnects from it. The metaspace grows or shrinks automatically as members connect to it and disconnect from it.
Initially, a metaspace contains only system spaces. As users create spaces in the metaspace, the definition of those spaces (along with other administrative data) is stored in system spaces.
If you implement the ActiveSpaces data persistence feature, you can persist data to local storage. However, space and field definitions are not persisted in existing spaces after the last metaspace disconnects from it.
If the metaspace is configured to make use of multicast for discovery, there is no need to provide a list of IP addresses of core metaspace members or to connect to it.
Multiple metaspaces may exist at the same time, each one containing a completely independent set of spaces. This means, for example, that changes to a space called clients in a metaspace named Dev have no impact on a space named clients in a metaspace named Prod. Since no single application can connect to two different metaspaces using the same metaspace name, metaspaces should always use different names.
RSS Feed
