Summary: Direct persistency mode support Read-Write Through
OverviewWhen running in direct persistency mode (i.e. Read-Write Through) the IMDG interacts with the External Data Source to persist its data where the client application would get the acknowledge for the IMDG operation only after both the IMDG and the External Data Source acknowledged the operation. With this persistency mode, the IMDG operations performance would be heavily depended on the speed of the External Data Source to commit the data and provide acknowledge back to the IMDG for the successful operation of the transaction. When having a mapping layer in between the IMDG and the External Data Source that converts the IMDG objects to relational database tables data (i.e. Hibernate), the time which takes to perform the conversion would also impact the acknowledge time and the application overall performance. The above means you should be careful when using this persistency mode in case your application have the requirement to respond quickly (low latency) and scale in linear manner.
When the application reading data from the IMDG there are two operational modes you should consider:
The Cache policy mode impacts also the initialization of the IMDG instance and the way it is reading data from the External Data Source to bootstrap itself.
Direct persistency mode supports the following database topologies: Central DatabaseWith the central database topology, a single database instance is used to store all the IMDG data. In this case only the primary IMDG instance will update the database. The backup IMDG instance will not update the database. The backup IMDG instance will update the database only once it will turn to be a primary in case of a failure or shutdown of the primary IMDG instance. A Data-Grid running in Direct persistency mode using central database topology, having all data within the IMDG would have the following configuration: <os-core:space id="space" url="/./space" schema="persistent" external-data-source="hibernateDataSource"> <os-core:properties> <props> <!-- Use ALL IN CACHE - No Read Performed from the database in lazy manner--> <prop key="space-config.engine.cache_policy">1</prop> <prop key="space-config.external-data-source.usage">read-write</prop> <prop key="cluster-config.cache-loader.external-data-source">true</prop> <prop key="cluster-config.cache-loader.central-data-source">true</prop> </props> </os-core:properties> </os-core:space> <bean id="hibernateDataSource" class="org.openspaces.persistency.hibernate.DefaultHibernateExternalDataSource"> <property name="sessionFactory" ref="sessionFactory"/> </bean> Distributed DatabasesWith the distributed databases topology, each IMDG instance uses its own database instance to store its data. In this case both the primary and the backup IMDG instances will update the database once IMDG operation is called or being replicated (to the backup). A Data-Grid running in Direct persistency mode using distributed databases topology (non-central), having all the data within the IMDG would have the following configuration: <os-core:space id="space" url="/./space" schema="persistent" external-data-source="hibernateDataSource"> <os-core:properties> <props> <!-- Use ALL IN CACHE - No Read Performed from the database in lazy manner--> <prop key="space-config.engine.cache_policy">1</prop> <prop key="space-config.external-data-source.usage">read-write</prop> <prop key="cluster-config.cache-loader.external-data-source">true</prop> <prop key="cluster-config.cache-loader.central-data-source">false</prop> </props> </os-core:properties> </os-core:space> <bean id="hibernateDataSource" class="org.openspaces.persistency.hibernate.DefaultHibernateExternalDataSource"> <property name="sessionFactory" ref="sessionFactory"/> </bean>
|
![]() |
GigaSpaces.com - Legal Notice - 3rd Party Licenses - Site Map - API Docs - Forum - Downloads - Blog - White Papers - Contact Tech Writing - Gen. by Atlassian Confluence |