Summary: This section explains the internals of the GigaSpaces XAP packaging and deployment unit, namely the processing unit. It explains how to create and run the processing unit in various runtime modes.

Overview

The processing unit is the unit of packaging and deployment in the GigaSpaces XAP platform.

This section details the processing unit's structure and the various processing unit types. The section includes an explanation of the directory structure, deployment descriptor, SLA attributes and how to debug, run and deploy the processing unit on the GigaSpaces XAP runtime environment.

Processing Units - The Packaging & Deployment Unit

GigaSpaces applications are comprised of one or more processing units. A processing unit is a set of DLL files which contain application classes, any other files it depends on, and a deployment descriptor, the pu.config file.

The processing unit is configured in the pu.config file which includes a number of GigaSpaces XML specific attributes. By defining these attributes, the processing unit creates it's own Service Level Agreement (SLA). The SLA can determine the number of processing unit instances, the deployment constraints for it (e.g. specific IP range), the topology of the data grid contained in it (see below) and more.

When a processing unit is deployed to the GigaSpaces runtime environment, one or more processing unit instances are created and associated with the running GigaSpaces containers. The number of processing unit instances depends on the configuration of the processing unit.

There are 3 types of processing units: Data only, business-logic only and mixed processing units, which contain both data and business logic. The data container for processing units is GigaSpaces In Memory Data Grid (IMDG) implementation, or the Space.

The space can be accessed via various APIs, and can be deployed in multiple topologies (which determine how the data is distributed across the cluster). It can be replicated (in which case the objects written to it are replicated across the cluster) or partitioned (in which case objects are distributed across multiple instances). If it is partitioned, it may also have backups for each partition.

Data only processing units

The Data Only processing unit defines a Space, and does not include any business logic. The processing unit defines the runtime characteristics of the space, for example, its runtime topology, the number of space replicas/partitions.

Business-logic only processing units

The Business-logic Only processing unit implements your application code, and does not include any data. Typically, your code interacts with a remote Space which is defined by another processing unit. By defining the processing unit as business logic only, you create an application server which is hosted and monitored by the GigaSpaces Service Grid. The application can be a typical dot net application deployed to a GigaSpaces processing unit.

Mixed processing units

The mixed processing unit defines both the business logic and a space. Typically, the business logic interacts with a local space instance (i.e. a data grid instance running within the same processing unit instance) to achieve lowest possible latency and best performance.

In such processing units, the processing unit state is directly related to that of the space instance it contains. If the space instance is in backup mode, the entire processing unit is in backup mode. This means that the business logic services which access the local space are not active. Upon failover, when the backup becomes primary, the backup business logic services also start working.

Section Contents

GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence