Note - Tutorial

1. VMs running GemFire discover each other through multicast messaging or a TCP location service, which is called a locator. The locator runs as a separate process to which each new VM connects to first discover the list of available peers.

2. The simplest type of of region is a replicated region. Every peer that hosts a replicated region stores a copy of the entire region locally. Changes to the replicated region are sent synchronously to all peers that host the region.

3. A partitioned region lets you control how many copies of your data will exist in the distributed system. The data is partitioned over all of the peers that host the partitioned region. GemFire automatically maintains the number of copies of each partition that you request.

The listener in only one of the VMs is invoked for each post. That's because partitioned regions choose one of the copies of the post to be the primary copy. By default GemFire only invokes the listener in the peer that holds the primary copy of each post.

4. Once you create a ClientCache, it maintains a pool of connections to the servers similar to a JDBC connection pool. However, with GemFire you do not need to retrieve connections from the pool and return them. That happens automatically as you perform operations on the regions. The pool locator property tells the client how to discover the servers. The client uses the same locator that the peers do to discover cache servers.

5. Setting the subscription enabled and subscription redundancy properties allow the client to subscribe to updates for entries that change in the server regions. You are going to subscribe to notifications about any people that are added. The updates are sent asynchronously to the client. Because the updates are sent asynchronously, they need to be queued on the server side. The subscription redundancy setting controls how many copies of the queue are kept on the server side. Setting the redundancy level to 1 means that you can lose 1 server without missing any updates.

6. Creating regions in the client is similar to creating regions in a peer. There are two main types of client regions, PROXY regions and CACHING_PROXY regions. PROXY regions store no data on the client. CACHING_PROXY regions allow the client to store keys locally on the client.


7. By creating a CACHING_PROXY, you told GemFire to cache any people that you create from this client. However, you can also choose to receive any updates to the people region that happen from other peers or other clients by invoking the registerInterest methods on the client. In this case you want to register interest in all people, so you cache the entire people regon on the client. The regular expression ".*" matches all keys in the people region.

8. You can dynamically add peers to the system while it is running. The new peers are automatically discovered by the other peers and the client. The new peers automatically receive a copy of any replicated regions they create. However, partitioned regions do not automatically redistribute data to the new peer unless you explicitly instruct GemFire to rebalance the partitioned region. With the cacheserver script, you can pass a command line flag indicating that the new peer should trigger a rebalance of all partitioned regions.

9. GemFire supports shared-nothing persistence. Each VM writes its portion of the region data to its own disk files. For the People region, each peer will be writing the entire region to its own disk files. For the Posts region a copy of each post will reside on two different peers.

10. When you restart persistent members, you need to call cacheserver start in parallel for each server.
The reason is that GemFire ensures that your complete data set is recovered before allowing the VMs to start. Remember that each VM is persisting only part of the Posts region. Each GemFire VM waits until all of the posts are available before starting. This protects you from seeing an incomplete view of the posts region.