Managed Objects can optionally have one or more keys defined using annotations. When a key is defined on a Managed Object, an index is maintained in shared memory as Managed Objects are created and deleted. An index associated with a replicated or distributed Managed Object is maintained on all nodes to which the object is exists.
By default key values are immutable - they cannot be changed after an object is created. Mutable keys are also allowed if explicitly specified in the key annotation.
Explicit transaction locking can be specified when doing a query. These lock types can be specified:
None - no transaction lock is taken on the objects returned by the query.
Read - a transaction read lock is taken on all objects returned by the query.
Write - a transaction write lock is taken on all objects returned by the query.
The lock type specified when performing a query only has impact on the query result. It does not affect the standard transaction locking as described in the section called “Locking” when operating on the objects returned from the query.
A query can be scoped to the local node only, a user defined sub-set of the nodes in a cluster, or all nodes in a cluster. This allows object instances to be located by key from any node in a cluster. When a query is executed on multiple remote nodes, the query executes in parallel and the result set is combined into a single result set returned to the caller . The returned result is guaranteed to contain only a single instance of an object if an object exists on multiple nodes (replicated or distributed).
If an object is returned from a remote node that doesn't already exist on the local node it is implicitly created on the local node. This causes a write lock to be taken for this object. The lock type specified when performing the query is ignored in this case. The caching of objects returned from remote nodes is controlled using Named Caches as described in the section called “Named Caches”.
When a user-defined query scope is used, the nodes in the query scope can be audited when the query is executed. The possible audit modes are:
Verify that the query scope contains at least one node. No other auditing is performed.
Verify that the query scope contains at least one node and that distribution is enabled. Any inactive nodes are skipped when a query is performed.
Verify that the query scope contains at least one node and that distribution is enabled. Any inactive nodes cause a query to fail with an exception.
Query support is provided for:
Unique and non-unique queries
Ordered and unordered queries
Range queries
Cardinality
Atomic selection of an object that is created if it does not exist