Summary: Reliable Asynchronous Persistency (Mirror)
OverviewThe GigaSpaces Mirror Service (also known as Persistency as a Service, or PaaS) provides reliable asynchronous persistency. This allows you to asynchronously delegate the operations conducted with the In-Memory-Data-Drid (IMDG) into a backend database, significantly reducing the performance overhead. The Mirror service ensures that data will not be lost in the event of a failure. This way, you can add persistency to your application just by running the Mirror Service, without touching the real-time portion of your application in either configuration or code. This service provides fine-grained control of which object needs to be persisted. Enabling the Mirror Service involves the following:
The above share the same External Data Source settings but have different space settings. See the Hibernate External Data Source for details how to use the built-in HibernateExternalDataSource. The Data-Grid Processing UnitThe cluster-config.mirror-service space settings specify the interaction between the IMDG primary spaces and the Mirror Service. The mirror="true" space element tag enables the replication mechanism from the IMDG Primary spaces to the Mirror Service. Once the mirror="true" is specified, all IMDG members will be Mirror aware and will be delegating their activities into the Mirror service. The IMDG primary instance will replicate the operations that have been logged within the primary redo log every interval-millis amount of time or interval-opers amount of operations. Both of these mechanisms are always active and the first one that is breached triggers the replication event. The IMDG Mirror replication settings includes the following options:
The Data-Grid Space settings would look like this: <os-core:space id="space" url="/./space" schema="persistent" mirror="true" external-data-source="hibernateDataSource"> <os-core:properties> <props> <!-- Use ALL IN CACHE - Read Only from the database--> <prop key="space-config.engine.cache_policy">1</prop> <prop key="space-config.external-data-source.usage">read-only</prop> <prop key="cluster-config.cache-loader.external-data-source">true</prop> <prop key="cluster-config.cache-loader.central-data-source">true</prop> <prop key="cluster-config.mirror-service.url">jini://*/mirror-service_container/mirror-service</prop> <prop key="cluster-config.mirror-service.bulk-size">100</prop> <prop key="cluster-config.mirror-service.interval-millis">2000</prop> <prop key="cluster-config.mirror-service.interval-opers">100</prop> <prop key="cluster-config.groups.group.repl-policy.repl-original-state">true</prop> </props> </os-core:properties> </os-core:space> <bean id="hibernateDataSource" class="org.openspaces.persistency.hibernate.DefaultHibernateExternalDataSource"> <property name="sessionFactory" ref="sessionFactory"/> </bean> The above example:
You must use a Data-Grid cluster schema that includes a backup (i.e. partitioned-sync2backup) when running a Mirror Service. Without having backup, the Primary IMDG Spaces will not replicate their activities to the Mirror Service. For testing purposes, in case you don't want to start backup spaces, you can use the partitioned-sync2backup cluster schema and have 0 as the number of backups - this will still allow the primary spaces to replicate their operations to the Mirror. The Mirror Processing UnitThe Mirror Service is constructed using the Space tag, however, the Mirror Service itself is not a regular Space. It is dispatching the operations which have been replicated from the IMDG primary spaces to the External Data Source (i.e. Database). The Mirror Service should be constructed as a separate processing unit, which includes only its definition. The following configuration shows how to configure a processing unit, to act as the Mirror Service: <os-sla:sla number-of-instances="1" /> <os-core:space id="mirror" url="/./mirror-service" schema="mirror" external-data-source="hibernateDataSource" /> <bean id="hibernateDataSource" class="org.openspaces.persistency.hibernate.DefaultHibernateExternalDataSource"> <property name="sessionFactory" ref="sessionFactory"/> </bean>
The Mirror PU ContentThe Mirror processing unit structure is shown below: -- example-mirror ------ META-INF ---------- spring -------------- pu.xml See the Processing Unit Structure for more information on the processing unit structure. The relevant Hibernate JAR file and its third party dependencies should be available to the mirror processing unit. The jar files should be placed in the processing unit lib directory. Optimizing the Mirror ActivityYou might want to tune the IMDG and the Mirror activity to push data into the database faster. Here are some recommendations you should consider:
With the above configuration the primary partition will replicate its redo log activities to the Mirror service every 5 seconds or every 50,000 operations. The replication will occur in batches of 10,000 objects per batch.
Advanced Information & Operations
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |