Original title: Spring certified China Education Management Center - spring data tutorial IV of Apache Geode (spring China Education Management Center)
5.5. 4. Compression
Apache Geode Regions may also be compressed to reduce JVM memory consumption and pressure, possibly avoiding global GC. When you enable compression for a Region, all values stored in the Region's memory are compressed, while keys and indexes remain uncompressed. New values are compressed when they are put into the Region, and all values are automatically decompressed when they are read back from the Region. Values are not compressed when saved to disk or sent over a line to other peer members or clients.
The following example shows an area where compression is enabled:
<beans>
<gfe:replicated-region id="exampleReplicateRegionWithCompression">
<gfe:compressor>
<bean class="org.apache.geode.compression.SnappyCompressor"/>
</gfe:compressor>
</gfe:replicated-region>
</beans>For more information about zone compression, see the documentation for Apache Geode.
5.5. 5. Out of pile
Apache Geode Regions can also be configured to store the Region value in off heap memory, which is part of JVM memory and is not affected by garbage collection (GC). By avoiding expensive GC cycles, your application can spend more time on important things, such as processing requests.
Using off heap memory is as simple as declaring the amount of memory to use and then enabling your region to use off heap memory, as shown in the following configuration:
<util:properties id="gemfireProperties">
<prop key="off-heap-memory-size">200G</prop>
</util:properties>
<gfe:cache properties-ref="gemfireProperties"/>
<gfe:partitioned-region id="ExampleOffHeapRegion" off-heap="true"/>You can control other aspects of off heap memory management by using the < GFE: cache > element to set the following Apache Geode configuration attributes: s
<gfe:cache critical-off-heap-percentage="90" eviction-off-heap-percentage"80"/>
Apache GeodeResourceManager will use these two thresholds( Critical off heap percentage & occurrence off heap percentage) to more effectively manage off heap memory in much the same way that the JVM does when managing heap memory. Apache GeodeResourceManager will prevent the cache from consuming too much off heap memory by evicting old data. If the out of heap memory manager cannot keep up, the resource manager refuses to add content to the cache until the out of heap memory manager frees up enough memory.
For more information on managing heap and off heap memory, refer to Apache Geode's documentation.
Specifically, read the "managing off heap memory" section.
5.5. 6. Subregion
Spring Data for Apache Geode also supports sub regions, allowing regions to be arranged in a hierarchical relationship.
For example, Apache Geode allows a / Customer/Address Region and a different / Employee/Address Region. In addition, a sub Region may have its own sub Region and configuration. A child Region does not inherit properties from its parent Region. Area types can be mixed and matched, subject to Apache Geode constraints. Sub Region is naturally declared as a child element of Region. The name attribute of sub Region is a simple name. The previous example may be configured as follows:
<beans>
<gfe:replicated-region name="Customer">
<gfe:replicated-region name="Address"/>
</gfe:replicated-region>
<gfe:replicated-region name="Employee">
<gfe:replicated-region name="Address"/>
</gfe:replicated-region>
</beans>Note that this Monospaced ([id]) attribute is not allowed for sub regions. Subareas are created using bean names (in this case, / Customer/Address and / Employee/Address, respectively). Therefore, they may be injected into other application beans that need them by using the full pathname of the zone, for example. The full pathname of the zone should also be used in the OQL query string.
5.5. 7. Area template
Spring Data for Apache Geode also supports Region templates.
This feature allows developers to define public Region configurations and properties at one time and reuse the configuration ApplicationContext in multiple Region bean definitions declared in Spring.
Spring Data for Apache Geode contains five Region template tags in its namespace:
In addition to the tag, the concrete < GFE: * - region > element (together with the abstract < GFE: * - region template > element) also has a template attribute to define the region template from which the region inherits its configuration. The region template can even inherit from other region templates.
The following example shows a possible configuration:
<beans>
<gfe:async-event-queue id="AEQ" persistent="false" parallel="false" dispatcher-threads="4">
<gfe:async-event-listener>
<bean class="example.AeqListener"/>
</gfe:async-event-listener>
</gfe:async-event-queue>
<gfe:region-template id="BaseRegionTemplate" initial-capacity="51" load-factor="0.85" persistent="false" statistics="true"
key-constraint="java.lang.Long" value-constraint="java.lang.String">
<gfe:cache-listener>
<bean class="example.CacheListenerOne"/>
<bean class="example.CacheListenerTwo"/>
</gfe:cache-listener>
<gfe:entry-ttl timeout="600" action="DESTROY"/>
<gfe:entry-tti timeout="300 action="INVLIDATE"/>
</gfe:region-template>
<gfe:region-template id="ExtendedRegionTemplate" template="BaseRegionTemplate" load-factor="0.55">
<gfe:cache-loader>
<bean class="example.CacheLoader"/>
</gfe:cache-loader>
<gfe:cache-writer>
<bean class="example.CacheWriter"/>
</gfe:cache-writer>
<gfe:async-event-queue-ref bean="AEQ"/>
</gfe:region-template>
<gfe:partitioned-region-template id="PartitionRegionTemplate" template="ExtendedRegionTemplate"
copies="1" load-factor="0.70" local-max-memory="1024" total-max-memory="16384" value-constraint="java.lang.Object">
<gfe:partition-resolver>
<bean class="example.PartitionResolver"/>
</gfe:partition-resolver>
<gfe:eviction type="ENTRY_COUNT" threshold="8192000" action="OVERFLOW_TO_DISK"/>
</gfe:partitioned-region-template>
<gfe:partitioned-region id="TemplateBasedPartitionRegion" template="PartitionRegionTemplate"
copies="2" local-max-memory="8192" persistent="true" total-buckets="91"/>
</beans>
Area templates also apply to sub areas. Please note“ "TemplateBasedPartitionRegion" extends "PartitionRegionTemplate", which extends "ExtendedRegionTemplate", which extends "BaseRegionTemplate". The attributes and child elements defined in the subsequent inherited Region bean definition will overwrite the content in the parent element.
How the template works
Spring Data for Apache Geode will apply the Region template when the ApplicationContext parses spring configuration metadata, so the Region template must be declared in the order of inheritance. In other words, the parent template must be defined before the child template. This ensures that the correct configuration is applied, especially when overriding element attributes or child elements.
It is also important to remember that the Region type can only inherit from other regions of similar types. For example, a cannot inherit < GFE: replicated Region > from a< gfe:partitioned-region-template>.
The area template is inherited by a single user.
Considerations for regions, subregions, and lookups
Previously, one of the basic attributes of replicated Region, partitioned Region, local Region, and client Region in the spring data element's Apache Geode XML namespace was the first attempt to create a Region before performing a lookup. This is done when the Region already exists. If the Region is in the imported Apache geode native cache This can happen if it is defined in the XML configuration file. Therefore, perform a lookup first to avoid any errors. This is due to design and may change.
This behavior has changed, and now the default behavior is to create an area first. If the Region already exists, the creation logic will quickly fail and throw an appropriate exception. However, very similar to the CREATE TABLE IF NOT EXISTS... DDL syntax, the Spring Data of the Apache geode < GFE: * - Region > XML namespace element now contains an ignore if exists attribute that restores the old behavior by first performing a lookup of the existing Region identified by name before attempting to create the Region. If an existing Region is found by name and ignore if exists is set to true, the Region bean definition defined in the Spring configuration is ignored.
The Spring team strongly recommends that only replicated Region, partitioned Region, local Region, and client Region XML namespace elements be strictly used to define new Regions. When the Regions defined by these elements already exist and the Region element performs search first, a possible problem is that if you define different Region semantics and behaviors for eviction, expiration, subscription, etc. in the application configuration, the Region definitions may not match and may show behaviors contrary to those required by the application. To make matters worse, you may want to define a Region as a distributed Region (for example, PARTITION), when in fact the existing Region definition is only local.
Recommended Practice - only elements of replicated region, partitioned region, local region, and client region XML namespaces are used to define new regions.
Consider the following native Apache geodecache XML configuration file:
<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns="https://geode.apache.org/schema/cache"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://geode.apache.org/schema/cache https://geode.apache.org/schema/cache/cache-1.0.xsd"
version="1.0">
<region name="Customers" refid="REPLICATE">
<region name="Accounts" refid="REPLICATE">
<region name="Orders" refid="REPLICATE">
<region name="Items" refid="REPLICATE"/>
</region>
</region>
</region>
</cache>Also, consider that you may have defined an application DAO as follows:
public class CustomerAccountDao extends GemDaoSupport {
@Resource(name = "Customers/Accounts")
private Region customersAccounts;
...
}Here, Customers/Accounts injects a reference to Region into the application DAO. Therefore, it is not uncommon for developers to define bean s for some or all of these regions in Spring XML configuration metadata, as shown below:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:gfe="https://www.springframework.org/schema/geode"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans https://www.springframework.org/schema/beans/spring-beans.xsd
https://www.springframework.org/schema/geode https://www.springframework.org/schema/geode/spring-geode.xsd
">
<gfe:cache cache-xml-location="classpath:cache.xml"/>
<gfe:lookup-region name="Customers/Accounts"/>
<gfe:lookup-region name="Customers/Accounts/Orders"/>
</beans>The Customers/Accounts and Customers/Accounts/Orders regions serve as references to Customers/Accounts and Customers/Accounts/Orders in the Spring container, respectively. The advantage of using the lookup region element and the corresponding syntax (described earlier) is that it allows you to directly reference the child region without defining a bean for the parent region (Customers in this case).
Consider the following error example, which changes the configuration metadata syntax to use nested format:
<gfe:lookup-region name="Customers">
<gfe:lookup-region name="Accounts">
<gfe:lookup-region name="Orders"/>
</gfe:lookup-region>
</gfe:lookup-region>Now consider another bad example, which uses the top-level replicated region element and the ignore if exists attribute set to perform the lookup first:
<gfe:replicated-region name="Customers" persistent="true" ignore-if-exists="true">
<gfe:replicated-region name="Accounts" persistent="true" ignore-if-exists="true">
<gfe:replicated-region name="Orders" persistent="true" ignore-if-exists="true"/>
</gfe:replicated-region>
</gfe:replicated-region>The region beanasapplicationcontext defined in Spring includes the following: {"Customers", "/Customers/Accounts"“ /Customers/Accounts/Orders "}. This means that the dependency injection reference shown in the previous example (i.e. @ resource (name =" Customers/Accounts ")) is now corrupted because Customers/Accounts actually does not define a bean with name. Therefore, you should not configure the area as shown in the previous two examples.
Apache Geode has the flexibility to reference parent and child regions with or without leading slashes. For example, a parent item can be referenced as / customers, and a child item can be referenced as / Customers/Accounts or Customers/Accounts. However, Apache Geode's Spring Data is very specific when naming bean s by region. It always uses a forward slash (/) to represent sub areas (for example, / Customers/Accounts).
Therefore, you should define a direct reference using the non nested syntax shown earlier in the lookup region or using a leading forward slash (/), as follows:
<gfe:lookup-region name="/Customers/Accounts"/> <gfe:lookup-region name="/Customers/Accounts/Orders"/>
The previous example, in which the nested replicated region element is used to reference a sub region, shows the problem described earlier. Are customer, account and order areas and sub areas persistent? They are not persistent because the region is in the local Apache geodecache It is defined in the XML configuration file and exists before the cache bean is initialized (once the < GFE: cache > element is processed).
5.5. 8. Data expulsion (overflow)
Based on various restrictions, each region can have an eviction policy to evict data from memory. Currently, in Apache Geode, eviction applies to least recently used entries (also known as LRU s). Evicted entries are either destroyed or paged to disk (called "overflow to disk").
Spring Data for Apache Geode supports all eviction policies (entry count, memory and heap usage) for partitioned regions, replicated regions, and client and local regions by using nested eviction elements.
For example, to configure a PARTITION Region to overflow to disk when the memory size exceeds 512 MB, you can specify the following configuration:
<gfe:partitioned-region id="examplePartitionRegionWithEviction"> <gfe:eviction type="MEMORY_SIZE" threshold="512" action="OVERFLOW_TO_DISK"/> </gfe:partitioned-region>
Replicas cannot be evicted using local destroy because it invalidates them. For more information, see the Apache Geode documentation.
When configuring Region for overflow, you should configure storage through the disk store element for maximum efficiency.
For a detailed description of the expulsion policy, please refer to the Apache Geode documentation on expulsion.