Configuring and Using Geode Regions and Locks for Atomic Data Structures

问题

I am currently using Spring Boot Starter 1.4.2.RELEASE, and Geode Core 1.0.0-incubating via Maven, against a local Docker configuration consisting of a Geode Locator, and 2 cache nodes.

I've consulted the documentation here:

http://geode.apache.org/docs/guide/developing/distributed_regions/locking_in_global_regions.html

I have configured a cache.xml file for use with my application like so:

<?xml version="1.0" encoding="UTF-8"?>
<client-cache
        xmlns="http://geode.apache.org/schema/cache"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://geode.apache.org/schema/cache
                        http://geode.apache.org/schema/cache/cache-1.0.xsd"
        version="1.0">
    <pool name="serverPool">
        <locator host="localhost" port="10334"/>
    </pool>
    <region name="testRegion" refid="CACHING_PROXY">
        <region-attributes pool-name="serverPool"
                scope="global"/>
    </region>
</client-cache>

In my Application.java I have exposed the region as a bean via:

@SpringBootApplication
public class Application {

    @Bean
    ClientCache cache() {
        return new ClientCacheFactory()
                .create();
    }

    @Bean
    Region<String, Integer> testRegion(final ClientCache cache) {
        return cache.<String, Integer>getRegion("testRegion");
    }

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

And in my "service" DistributedCounter.java:

@Service
public class DistributedCounter {

@Autowired
private Region<String, Integer> testRegion;

/**
 * Using fine grain lock on modifier.
 * @param counterKey {@link String} containing the key whose value should be incremented.
 */
public void incrementCounter(String counterKey) {
    if(testRegion.getDistributedLock(counterKey).tryLock()) {
        try {
            Integer old = testRegion.get(counterKey);
            if(old == null) {
                old = 0;
            }
            testRegion.put(counterKey, old + 1);
        } finally {
            testRegion.getDistributedLock(counterKey).unlock();
        }
    }
}

I have used gfsh to configure a region named /testRegion - however there is no option to indicate that it's type should be "GLOBAL", only a variety of other options are available - ideally this should be a persistent, and replicated cache though so the following command:

create region --name=/testRegion --type=REPLICATE_PERSISTENT

Using the how-to at: http://geode.apache.org/docs/guide/getting_started/15_minute_quickstart_gfsh.html it is easy to see the functionality of persistence and replication on my two node configuration.

However, the locking in DistributedCounter, above, does not cause any errors - but it just does not work when two processes attempt to acquire a lock on the same "key" - the second process is not blocked from acquiring the lock. There is an earlier code sample from the Gemfire forums which uses the DistributedLockService - which the current documentation warns against using for locking region entries.

Is the use-case of fine-grained locking to support a "map" of atomically incremental longs a supported use case, and if so, how to appropriately configure it?

回答1:

The Region APIs for DistributedLock and RegionDistributedLock only support Regions with Global scope. These DistributedLocks have locking scope within the name of the DistributedLockService (which is the full path name of the Region) only within the cluster. For example, if the Global Region exists on a Server, then the DistributedLocks for that Region can only be used on that Server or on other Servers within that cluster.

Cache Clients were originally a form of hierarchical caching, which means that one cluster could connect to another cluster as a Client. If a Client created an actual Global region, then the DistributedLock within the Client would only have a scope within that Client and the cluster that it belongs to. DistributedLocks do not propagate in anyway to the Servers that such a Client is connected to.

The correct approach would be to write Function(s) that utilize the DistributedLock APIs on Global regions that exist on the Server(s). You would deploy those Functions to the Server and then invoke them on the Server(s) from the Client.

In general, use of Global regions is avoided because every individual put acquires a DistributedLock within the Server's cluster, and this is a very expensive operation.

You could do something similar with a non-Global region by creating a custom DistributedLockService on the Servers and then use Functions to lock/unlock around code that you need to be globally synchronized within that cluster. In this case, the DistributedLock and RegionDistributedLock APIs on Region (for the non-Global region) would be unavailable and all locking would have to be done within a Function on the Server using the DistributedLockService API.

回答2:

It seems that GFSH does not provide an option to provide the correct scope=GLOBAL.

Maybe you could start a server with --cache-xml-file option... which would point to a cache.xml file.

The cache.xml file should look like this:

<?xml version="1.0" encoding="UTF-8"?>
<cache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schema.pivotal.io/gemfire/cache" xsi:schemaLocation="http://schema.pivotal.io/gemfire/cache http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd" version="8.1" lock-lease="120" lock-timeout="60" search-timeout="300" is-server="true" copy-on-read="false">
<cache-server port="0"/>
<region name="testRegion">
    <region-attributes data-policy="persistent-replicate" scope="global"/>
</region>
</cache>

Also the client configuration does not need to define the scope in region-attributes

回答3:

This only works for server side code (in Functions for example).

From client code you can implement locking semantics using "region.putIfAbsent".

If 2 (or more) clients call this API on the same region and key, only one will successfully put, which is indicated by a return value of null. This client is considered to hold the lock. The other clients will get the object that was put by the winner. This is handy because, if the value you "put" contains a unique identifier of the client, then the losers even know who is holding the lock.

Having a region entry represent a lock has other nice benefits. The lock survives across failures. You can use region expiration to set the maximum lease time for a lock, and, as mentioned previously, its easy to tell who is holding the lock.

Hope this helps.

来源：https://stackoverflow.com/questions/40849857/configuring-and-using-geode-regions-and-locks-for-atomic-data-structures

标签

apache

geode