Disk stores provide disk storage for all persistence and overflow in the distributed system. This storage is used for regions, server client subscription queues, and WAN gateway queues.
The new functionality includes storage for multiple regions and queues within the same disk store; automated and manual compaction options for operation log files; command-line management of disk store files; and startup with automatic initialization from the most recent data on disk (so you do not need to track which members have the most recent data).
You can now persist your partitioned region data to disk. The data is written to disk by each data store for the region, so buckets are stored on disk on the same hosts where they are stored in memory. The system also has a new shutdown command that positions persistent partitions for recovery from disk on the next startup, rather than recovering through transfers between members across the network.
Clients can send individual data requests – such as put and delete – in a single hop, directly to the server holding the data key. The clients store metadata about bucket locations for partitioned region data. This feature improves performance and client access to partitioned regions in the server tier. Before this release, the server was chosen based solely on load and preexisting connections. So if the data was not on the chosen server, another server-to-server communication hop was required to get to the data.
Transactions are modified to expand functionality, including the addition of partitioned regions in transactions; a TransactionWriter for synchronized commit event handling; and function execution compatibility with transactions.
GemFire now supports running multiple, distinct users in your client applications. This feature accommodates installations where GemFire clients are embedded in application servers, and each application server supports data requests from many users. Each user may be authorized to access a small subset of data on the servers, as in a customer application where each customer can access only their own orders and shipments. Each user in the client connects to the server with its own set of credentials, and is given its own access authorization to the server cache.
Client/server communication has increased security against replay attacks. The server now sends the client a unique, random identifier with each response, to be used in the next client request. Because of the identifier, even a repeated client operation call is sent as a unique request to the server.
GemFire now partitions subscription management (interest registration and continuous queries) across server data stores, ensuring that a subscription is processed only once for all interested clients. The resulting improvements in CPU use and bandwidth utilization improve throughput and reduce latency for client subscriptions.
Delta propagation in GemFire reduces distribution costs by distributing only the difference between old and new versions of an object - the delta - instead of sending the new object in its entirety. The delta is applied in the receiving caches to the local copies of the object. The cost savings can be significant, especially when changes to an object instance are relatively small compared to the overall size of the instance.
The initial result set returned to continuous query (CQ) execution now includes the entry keys. This feature makes is easier to maintain result sets on the client. The initial result set correlates directly to subsequent CQ results in the listener.
The APIs for connecting, creating a cache, and managing regions are updated for ease of use. The distributed system is now created automatically when you create your cache. If only one server connection pool is defined, client regions automatically use that pool. The system provides shortcuts for the most common region configurations, to lessen the amount of region attributes you need to specify.
The function execution service now offers high availability execution for onRegion functions that return a result. Also, a function invoked using the FunctionId no longer has to be registered in the calling application. It only has to be registered in the application where it is run.
These enhancements were available in prior releases as early access features:
You can configure your gateway hubs for load balancing. You can configure gateway hubs for manual start, so hubs defined in your cache.xml file do not start when the cache is created. You can use your gateway hubs to implement write-behind cache listeners.
A cache server is now always started by the "cacheserver start" command.
You can now use one set of configuration files for your cacheserver processes, and override the port and/or bind address for each server, at the command line.
The gemfire command-line utility has a new function for shutting down the entire distributed system in an orderly fashion. This feature is particularly useful for persistent regions because it enables more efficient startup the next time you run the system.
The Gemfire command-line utility supports orderly system shutdown and the new disk stores.
You can retrieve serialized values from EntryEvent. If you get values from one region's events, you can put them into a separate cache region. The standard getOldValue and getNewValue functions deserialize the values, which would then be reserialized when you put them into the cache. There is no counterpart put function as the put recognizes that the value is serialized and bypasses the serialization step.
The Region.getAll method gets values for all keys in the specified collection. The method returns a map of values for the input keys.
With logging, if you set the gemfire.properties log-file-size-limit, the system rolls to a new file each time the limit is reached by the current log file. Before this release, the current log (the one being written to) was the log with the highest sequence number. Now, the current log is always the one named with the log-file you specify in the gemfire.properties. When the log rolls forward, the current log is renamed to the next higher sequence number and a new file named log-file is created as the current log file. This feature allows you to monitor the one file, rather than needing to change file names as the current file name rolls forward. For details, see the chapter on Logging in the GemFire Enterprise System Administrator's Guide.
You can now configure every port used by GemFire. This makes GemFire easier to manage and more security friendly. This version includes a new membership-port-range gemfire property to configure the range of ports available for unicast UDP messaging and for TCP failure detection.
This version adds numerous improvements to the GemFire JMX agent.
For details on everything new to GemFire 6.5, see the Release Notes.