POJO Support

Search XAP 7.0
Searching XAP 7.0.X Documentation
Browse XAP 7.0
Offline Documentation

Download latest offline documentation in HTML format:
xap-7.0.2-documentation.zip (12.3MB)

                                                              

Summary: GigaSpaces JavaSpaces API Plain Old Java Object support - the POJO.

Overview

GigaSpaces JavaSpaces POJO support allows you to use JavaBean classes as space domain classes, and perform space operations using these objects. POJO domain Classes should follow rules similar to the ones defined by JPA, Hibernate and other domain class frameworks.

GigaSpaces POJO rules:

  • Do not implement the net.jini.core.entry interface.
  • Follow the JavaBeans specification.
  • Have private fields.
  • Have primitive types (int, boolean, etc.) fields.
  • Have getter and setter methods.
  • Include space class metadata decorations (indexed fields, affinity-keys, persisted mode, etc.).
    You can define space classes metadata by class and field level decorations. These can be defined via annotations (supported in JVM 1.5 and above) or XML configurations files (gs.xml file, supported from JVM 1.4).

    This page deals with the POJO class as a space domain class, used to model the space, and store application data into the IMDG.

POJO classes deployed as services into the Service Grid are described in the Data Event Listener and Space Based Remoting sections. In these cases, the POJO class is used to process incoming data, or is invoked remotely.

A POJO as a Space Domain Class

Guidelines

When using a POJO as a space domain class, follow these guidelines:

  • A POJO class must implement a default (zero argument) constructor.
  • A POJO class cannot implement the net.jini.core.entry interface; otherwise, it is treated differently.
  • A POJO class should have space class metadata decorations using annotations or a gs.xml file with relevant metadata (indexed field list, version field, FIFO mode, persistency mode, primary key (i.e. id)). If neither are provided, the defaults are presumed. (The default settings might not always match your needs.)
  • Getter/setter methods for fields that you want to be persisted in the space.
  • Non-primitive fields must implement Serializable or Externalizable. For example, if you are using a POJO class that contains a nested class.
  • When performing matching/queries using primitive fields (int , long , double, etc.) the nullValue annotation or null-value tag must be specified with relevant values, to function correctly.
    @SpaceProperty(nullValue="-1")
    public int getEmployeeID()
    {
    	return employeeID;
    }
  • The UID can be determined using the @SpaceId annotation or the id tag.
  • When using POJOs, the write operation uses the
    UpdateModifiers.UPDATE_OR_WRITE mode by default. This means that when the space already includes an object with the same UID (@SpaceId(autoGenerate=false) with the same value), the POJO is updated, and a new object is not inserted.
  • When using SpaceId(autoGenerate=true), the UID is stored inside the SpaceId field, causing an overhead when indexed.
  • TokenQuery is not supported with POJOs.
  • POJO space mapping files gs.xml files can be loaded from:
    • <CLASSPATH>\config\mapping folder, or
    • The same package where the class file is located using the format <<Class Name>>.gs.xml.
  • A null value as template is not supported. Use new Object() instead.
  • FIFO mode is supported only at the POJO class level. You can't specify a template with fifo=false and write an object with fifo=true. You should use a different space proxy in such cases.
  • A POJO class must implement the Serializable or Externalizable interface if used as a parameter for a remote call (OpenSpaces remoting).
  • When using the org.openspaces.core.GigaSpace

    interface, you can use generics when conducting space operations.

  • The @Spaceid annotation or id tag must be declared when performing update operations.
  • To persist a POJO object using the ExternalDataSource , Mirror Service, JDBC Storage Adapter, or indexed file options, the persist decoration must have the value true.
  • When a space is configured to use the ExternalDataSource, the @Spaceid annotation or id tag auto-generate attribute should be set to false. The object must include a unique value with the SpaceId field when written into the space.
  • The SpaceId field can be java.lang.String type or any other type that implements the toString() which provides  a unique value.
  • All net.jini.core.entry.Entry based classes meta data methods are not supported with POJO based classes. These include: _setEntryInfo() , __getEntryInfo() , __setEntryUID() , __getEntryUID() ,_getSpaceIndexedFields(). With POJO based space domain classes, meta data is declared using relevant annotations or xml tags.
  • Primitive boolean should not be used as a POJO field as this could lead to problems when doing template matching. Boolean should be used instead.
  • In order to query a base abstract class you, due to the fact that one can't create an instance of an abstract class, SQLQuery should be used.

Batch Operations

  • Batch operations boost performance, since they interact with the server in one call, and retrieve the result from the space with one space operation. This allows the client and server to utilize the network bandwidth in an efficient manner - in some cases, up to 10 times faster than single based operations.
  • readMultiple should be handled with care, since it can return a large data set (potentially all the space data). This might cause an out of memory error in the space and client process. You should use the GSIterator to return the result in batches in such cases.
  • Destructive batch operations (take , write , update) should be performed with transactions - this allows the client to roll back the space to its initial state before the operation was started, in case of a failure.
  • When calling writeMultiple or updateMultiple, make sure null values are not part of the passed array.
  • When using writeMultiple, you should verify that duplicated entries (with the same ID) do not appear as part of the passed array, since the identity of the object is determined based on its ID and not based on its reference. This is extremely important with an embedded space, since writeMultiple injects the ID value into the object after the write operation.
  • readMultiple and takeMultiple do not support timeout operations. The simple way to achieve this is by calling the read operation with the proper timeout, and if non-null values are returned, perform the batch operation.

Code Snippets

Space operations with POJO objects can be conducted using the org.openspaces.core.GigaSpace interface or the com.j_spaces.core.IJSpace interface.

The code snippets below use the org.openspaces.core.GigaSpace interface that is the recommended interface.


Next subchapter: POJO Support - Advanced - This advanced section deals with the annotations and gs.xml mapping file, troubleshooting procedures, considerations, UID generation and usage, as well as frequently used code snippets.

IMPORTANT: This is an old version of GigaSpaces XAP. Click here for the latest version.

Labels

 
(None)