Modification performed on a GigaSpaces cluster can be asynchronously received in a central process. This process is the Mirror Service (see Mirror Service official documentation )
This concept is used mostly for two scenarios:
Mirror Service allows to provide your own logic to deal with batches of modification by implementing the BulkDataPersister interface. While powerful this does not allow to configure multiple implementation at the same time.
A solution to workaround this is to implement a specific BulkDataPersister which will internally dispatch to concrete implementations. Composite BulkDataPersister is a generic implementation of this pattern allowing to simply configure multiple concrete BulkDataPersister used by a Mirror Service. Simply configure your regular BulkDataPersister implementations (using either regular property file or spring injection) and configure Mirror Service to use Composite BulkDataPersister. Internally a thread pool will be used to delegate in parallel execution of all implementations and.
This approach leads to a possible inconsistency between BulkDataPersisters in case one of the delegates fails. A generic strategy can be provided to handle partial failures. One of the default strategy uses another space to store all information related to a particular failure. Ultimately if the strategy itself fails exception is propagated to the Mirror Service which will trigger the redo-log mechanism (so one batch might be received several time by a delegate).
Eventually transaction usage might be implemented.
