Initial Cache Load

When the space is started, restarted or cleaned, the system can initially fill the space with entries that are likely to be required by the application. You can specify the data to be used by the LifeCycleManager and the SpaceFilter.

The CacheLoader.loadAll or, if implemented, the CacheFactory.iterator methods are called when the space is started. The CacheQuery argument encapsulates an IGSEntry that has as part of its class name java.lang.object.

This interface can be used to load the space with data to speed up later operations. The space is not available for clients until the data load process has been completed.

Eliminating resonance affect when using the Mirror Service When using the Mirror Service and having the CacheLoader implemented for the space - All data loaded into the space while is it started using the CacheLoader.loadAll or CacheFactory.iterator with the java.lang.object as the class type as part of the ((IGSEntry)CacheQuery.getQuery()).getClassName() will not be replicated back to the mirror.

Count Operation

The scope of IJSpace.count() and IMap.Size() is the data stored within the space. These methods do not take into account the data stored within the underlying data source.
When using the Map with a local cache the value of IMap.Size() will be the amount of objects with in the local cache (it could be less than what is actually in the space).

Recursive Calls

The CacheLoader/Store should avoid calling the space to avoid deadlock and internal thread pool exhaustion.

UID Generation

The space embeds a unique identifier to each Entry (UID). This UID is used implicitly when performing update operations, and read/take operations based on UID.
When using the CacheLoader/Store mechanism, to ensure the consistency of the system, it is desirable to embed the UID into the object when writing the Entry into the space and when loading it from the underlying data source. To maintain coherency when using the CacheLoader mechanism, the UID should be based on some unique value stored within the object, such as the primary key. This unique value is used when generating the Entry UID. You can generate the UID yourself or instruct GigaSpaces to use a specific Entry field value as the basis for the Entry UID.

The following describes the various options to determine the UID or the Object Class field to be used as the basis for the Entry UID.

You should ensure that the field to be used as the basis for the UID holds a unique value per object. When trying to write into the space or loading an object that has an UID that already exists within the space the operation is rejected with the exception: com.j_spaces.core.client.EntryAlreadyInSpaceException.

UID Generation for POJO and Entry Objects

You can use configuration files, annotations or API to determine the Entry's UID.
The priority for the UID generation is:

1. Configuration files (gs.xml).
2. Annotations.
3. API.

The above search order means that configuration files override Annotations, and Annotations override API.

UID for POJO Objects

When using JavaSpace API with POJO objects, the following options determine the field to be used as the basis for the UID.

• gs.xml – the gs.xml defines the meta data to be used when mapping Entry/POJO to the space. The <Key> tag defines the field to be used as the basis for the UID.
• @Key annotation – you can use the method level @Key annotation to determine the field to be used as the basis for the UID value.

  Since annotations are not supported with JDK 1.4 you should use gs.xml files to define the class metadata.

UID for Entry Objects

When using JavaSpace API with Entry objects, the rules are same as for POJO objects with the additional option to define the field name to be used as the basis for the UID generation: the first indexed field – i.e. the first element, of the array returned from the public static String[] __getSpaceIndexedFields() __ method.

The ClientUIDHandler can be used with classes extends MetaDataEntry or implement IMetaDataEntry to explicitly determine the Entry UID.

When no field is defined to be the basis for the Entry UID, the UID is generated by the space using sequencer mechanism, which could lead to inconsistent behavior.

When using ExternalEntry objects (mainly for C# or C++ applications), you can determine the field to be used as basis for the UID generation by using the IGSEntry.setPrimaryKeyName() method. The IGSEntry.getPrimaryKeyName() returns the field name to be used as basis for the UID.

Space configuration files and annotations do not support ExternalEntry objects.