org.apache.ignite.configuration

## Enum DeploymentMode

- java.lang.Object
- - java.lang.Enum<DeploymentMode>
  - - org.apache.ignite.configuration.DeploymentMode

- All Implemented Interfaces:
    Serializable, Comparable<DeploymentMode>

      public enum DeploymentMode
      extends Enum<DeploymentMode>

  Grid deployment mode. Deployment mode is specified at grid startup via `IgniteConfiguration.getDeploymentMode()` configuration property (it can also be specified in Spring XML configuration file). The main difference between all deployment modes is how classes are loaded on remote nodes via peer-class-loading mechanism.

  The following deployment modes are supported:

  - `PRIVATE`
  - `ISOLATED`
  - `SHARED`
  - `CONTINUOUS`

  # User Version

  User version comes into play whenever you would like to redeploy tasks deployed in `SHARED` or `CONTINUOUS` modes. By default, Ignite will automatically detect if class-loader changed or a node is restarted. However, if you would like to change and redeploy code on a subset of nodes, or in case of `CONTINUOUS` mode to kill the ever living deployment, you should change the user version.

  User version is specified in `META-INF/ignite.xml` file as follows:

          <!-- User version. -->
          <bean id="userVersion" class="java.lang.String">
              <constructor-arg value="0"/>
          </bean>

  By default, all ignite startup scripts (`ignite.sh` or `ignite.bat`) pick up user version from `IGNITE_HOME/config/userversion` folder. Usually, it is just enough to update user version under that folder, however, in case of `GAR` or `JAR` deployment, you should remember to provide `META-INF/ignite.xml` file with desired user version in it.

  # Always-Local Development

  Ignite deployment (regardless of mode) allows you to develop everything as you would locally. You never need to specifically write any kind of code for remote nodes. For example, if you need to use a distributed cache from your `ComputeJob`, then you can the following:
  1. Simply startup stand-alone Ignite nodes by executing `IGNITE_HOME/ignite.{sh|bat}` scripts.
  2. Now, all jobs executing locally or remotely can have a single instance of cache on every node, and all jobs can access instances stored by any other job without any need for explicit deployment.

- - ### Enum Constant Summary

    Enum Constants
    Enum Constant and Description
    `CONTINUOUS` Same as `SHARED` deployment mode, but resources will not be undeployed even after all master nodes left grid.
    `ISOLATED` Unlike `PRIVATE` mode, where different deployed tasks will never use the same instance of resources, in `ISOLATED` mode, tasks or classes deployed within the same class loader will share the same instances of resources.
    `PRIVATE` In this mode deployed classes do not share resources.
    `SHARED` Same as `ISOLATED`, but now tasks from different master nodes with the same user version and same class loader will share the same class loader on remote nodes.

  - ### Method Summary

    All Methods Static Methods Concrete Methods
    Modifier and Type | Method and Description
    --- | ---
    `static @Nullable DeploymentMode` | `fromOrdinal(int ord)` Efficiently gets enumerated value from its ordinal.
    `static DeploymentMode` | `valueOf(String name)` Returns the enum constant of this type with the specified name.
    `static DeploymentMode[]` | `values()` Returns an array containing the constants of this enum type, in the order they are declared.

    - ### Methods inherited from class java.lang.Enum

      `clone, compareTo, equals, finalize, getDeclaringClass, hashCode, name, ordinal, toString, valueOf`

    - ### Methods inherited from class java.lang.Object

      `getClass, notify, notifyAll, wait, wait, wait`

- - ### Enum Constant Detail

    - #### PRIVATE

          public static final DeploymentMode PRIVATE

      In this mode deployed classes do not share resources. Basically, resources are created once per deployed task class and then get reused for all executions.

      Note that classes deployed within the same class loader on master node, will still share the same class loader remotely on worker nodes. However, tasks deployed from different master nodes will not share the same class loader on worker nodes, which is useful in development when different developers can be working on different versions of the same classes.

      Also note that resources are associated with task deployment, not task execution. If the same deployed task gets executed multiple times, then it will keep reusing the same user resources every time.

    - #### ISOLATED

          public static final DeploymentMode ISOLATED

      Unlike `PRIVATE` mode, where different deployed tasks will never use the same instance of resources, in `ISOLATED` mode, tasks or classes deployed within the same class loader will share the same instances of resources. This means that if multiple tasks classes are loaded by the same class loader on master node, then they will share instances of resources on worker nodes. In other words, user resources get initialized once per class loader and then get reused for all consecutive executions.

      Note that classes deployed within the same class loader on master node, will still share the same class loader remotely on worker nodes. However, tasks deployed from different master nodes will not share the same class loader on worker nodes, which is especially useful when different developers can be working on different versions of the same classes.

    - #### SHARED

          public static final DeploymentMode SHARED

      Same as `ISOLATED`, but now tasks from different master nodes with the same user version and same class loader will share the same class loader on remote nodes. Classes will be undeployed whenever all master nodes leave grid or user version changes.

      The advantage of this approach is that it allows tasks coming from different master nodes share the same instances of resources on worker nodes. This allows for all tasks executing on remote nodes to reuse, for example, the same instances of connection pools or caches. When using this mode, you can startup multiple stand-alone Ignite worker nodes, define resources on master nodes and have them initialize once on worker nodes regardless of which master node they came from.

      This method is specifically useful in production as, in comparison to `ISOLATED` deployment mode, which has a scope of single class loader on a single master node, this mode broadens the deployment scope to all master nodes.

      Note that classes deployed in this mode will be undeployed if all master nodes left grid or if user version changed. User version can be specified in `META-INF/ignite.xml` file as a Spring bean property with name `userVersion`. This file has to be in the class path of the class used for task execution.

      `SHARED` deployment mode is default mode used by the grid.

    - #### CONTINUOUS

          public static final DeploymentMode CONTINUOUS

      Same as `SHARED` deployment mode, but resources will not be undeployed even after all master nodes left grid. Tasks from different master nodes with the same user version and same class loader will share the same class loader on remote worker nodes. Classes will be undeployed whenever user version changes.

      The advantage of this approach is that it allows tasks coming from different master nodes share the same instances of resources on worker nodes. This allows for all tasks executing on remote nodes to reuse, for example, the same instances of connection pools or caches. When using this mode, you can startup multiple stand-alone Ignite worker nodes, define resources on master nodes and have them initialize once on worker nodes regardless of which master node they came from.

      This method is specifically useful in production as, in comparison to `ISOLATED` deployment mode, which has a scope of single class loader on a single master node, `CONTINUOUS` mode broadens the deployment scope to all master nodes.

      Note that classes deployed in `CONTINUOUS` mode will be undeployed only if user version changes. User version can be specified in `META-INF/ignite.xml` file as a Spring bean property with name `userVersion`. This file has to be in the class path of the class used for task execution.

  - ### Method Detail

    - #### values

          public static DeploymentMode[] values()

      Returns an array containing the constants of this enum type, in the order they are declared. This method may be used to iterate over the constants as follows:

          for (DeploymentMode c : DeploymentMode.values())
              System.out.println(c);

      Returns:
        an array containing the constants of this enum type, in the order they are declared

    - #### valueOf

          public static DeploymentMode valueOf(String name)

      Returns the enum constant of this type with the specified name. The string must match exactly an identifier used to declare an enum constant in this type. (Extraneous whitespace characters are not permitted.)
      Parameters:
        `name` - the name of the enum constant to be returned.
      Returns:
        the enum constant with the specified name
      Throws:
        `IllegalArgumentException` - if this enum type has no constant with the specified name
        `NullPointerException` - if the argument is null

    - #### fromOrdinal

          @Nullable
          public static @Nullable DeploymentMode fromOrdinal(int ord)

      Efficiently gets enumerated value from its ordinal.
      Parameters:
        `ord` - Ordinal value.
      Returns:
        Enumerated value.

${current.year} Copyright © Apache Software Foundation
| Follow @ApacheIgnite
Ignite Database and Caching Platform | : ver. 2.15.0
Release Date | : April 25 2023