Coherence 3.7 New Features Overview - Oracle

Schedule: Timing Topic 45 minutes Lecture 00 minutes Practice 45 minutes Total

Coherence 3.7 New Features Overview



Coherence new features fall into four main areas: ease of use; integration; reliability, availability, scalability and performance; and innovation. Each of these dozen or more major improvements is supported by many more minor improvements.



Clients currently discover proxy servers via a static list of proxy listen addresses and ports. When additional proxy servers are added to the cluster, client configuration must be updated for the new capacity to be utilized. This could only be improved by using a WKA-like approach. The client configuration would need the address of only one proxy server. This proxy server could then redirect connect requests to another proxy, perhaps based on connection count or server utilization. This will result in a better distribution of clients across proxy servers.


Load balancing has been provided in Coherence 3.7 in two ways. First, the default proxy-based mechanism has been improved to better load balance. In general, the proxy-based load balancing algorithm distributes client connections equally across proxy service members. The algorithm redirects clients to proxy services that are being utilized the least. The following factors are used to determine a proxy’s utilization:

•  Connection Utilization – This utilization is calculated by adding the current and pending connection counts. If a proxy has a configured connection limit and the current plus pending connection counts equals the connection limit, the utilization is considered to be infinite.

•  Daemon Pool Utilization – This utilization equals the current number of active daemon threads. If all daemon threads are currently active, the utilization is considered to be infinite.

•  Message Backlog Utilization – This utilization is calculated by adding the current incoming and current outgoing message backlogs.

Coherence 3.7 also saw the addition of the com.tangosol.coherence.net.proxy package which includes the APIs that support develop custom plug-ins to balance client load across proxy service members based on specific client algorithms.


Prior versions of Coherence provide Document Type Definitions (DTD) files that define the structure of the different configuration files used by the product. DTDs are limited in definition capabilities—a feature which limits the level of validation (for example, type checking) that can be performed on the configuration files. Providing XSD files will improve the end-user experience for Coherence because end users will be able to validate their configuration files more accurately by using XML editors.




Two new annotations have been added to support automated generation of POF serialers, which greatly simplifies POF development. Two attributes are available to indicate that a class and its properties are POF serializable:

•  @Portable – Marks the class as POF serializable. The annotation is permitted only at the class level and has no members.

•  @PortableProperty – Marks a member variable or method accessor as a POF-serialized attribute. Annotated methods must conform to accessor notation (get, set, is).



Starting with Coherence 3.7 and Oracle GlassFish Server 3.1, there is a new feature of Coherence*Web called ActiveCache for GlassFish. ActiveCache for GlassFish provides Coherence*Web functionality in web applications deployed on Oracle GlassFish Servers.


Coherence now supports load balancing via F5. The F5 BIG-IP LTM is a hardware device that sits between one or more computers running Coherence*Extend clients and one or more computers running Coherence*Extend proxy servers. The LTM spreads client connections across multiple clustered proxy servers by using a broad range of techniques to secure, optimize, and load balance application traffic.


Coherence REST provides easy access to Coherence caches and cache entries over HTTP protocol. It is somewhat similar to Coherence*Extend, because it enables remote clients to access data that is stored in Coherence without being members of the cluster themselves. However, unlike Coherence*Extend, which is a proprietary protocol that requires POF serialization to be used both on the client and within the cluster, Coherence REST uses HTTP as the underlying protocol and can marshal data in multiple representation formats, such as JSON and XML. The benefit of Coherence REST is that it enables applications written in other languages, such as Ruby and Python (that are not natively supported by Coherence), to interact with cached data.


Coherence REST supports both XML and JSON formats as input and output. To use these formats, the correct bindings are required when creating a user type. Objects that are represented in XML must have the appropriate JAXB bindings defined in order to be stored in a cache. Objects that are represented in JSON must have the appropriate Jackson bindings or JAXB bindings defined in order to be stored in a cache. The default Coherence REST JSON marshaller gives priority to Jackson bindings, and if not found, fails safe to JAXB bindings. Using Jackson annotations gives users more power over controlling the output JSON format. In cases where both, XML and JSON formats are needed, JAXB annotations can be used which supports both formats.



Coherence 3.7 introduces a new feature to Coherence queries familiar to most database developers, the explain plan and trace command. The EXPLAIN PLAN FOR and TRACE commands are used to create and output query records that are used to determine the cost and effectiveness of a query. A query explain record provides the estimated cost of evaluating a filter as part of a query operation. A query trace record provides the actual cost of evaluating a filter as part of a query operation. Both query records take into account whether or not an index can be used by a filter.



Coherence 3.7 introduces a number of new JMX monitoring variables focused on query optimization, such as the following:

•  OptimizedQueryCount - The total number of queries that were fully resolved using indexes since the statistics were last reset

•  NonOptimizedQueryCount - The total number of parallel queries that could not be resolved (or that were partially resolved) using indexes since the statistics were last reset

•  OptimizedQueryAverageMillis - The average duration, in milliseconds, per optimized query execution since the statistics were last reset

•  NonOptimizedQueryAverageMillis - The average duration, in milliseconds, for non-optimized query execution since the cache statistics were last reset

•  MaxQueryDescription - A description of the query with the longest duration that exceeds the MaxQueryThresholdMillis attribute since the statistics were last reset

•  And other new JMX monitoring variables






The benefits of elastic data versus a simple distributed scheme are many: •  Because of the use and nature of journaling, up to 4x objects may be stored in memory

as compared to prior versions of coherence. •  With journaling and compression, datasets of 100 GB can be managed on single cluster

members. •  Self-tuning – Elastic data can self tune and track object use, rebalancing the internal

tree structures to maintain the most commonly used data in memory. •  Java garbage collection is minimized as a result of the tree-based journals used to

manage data. •  It is very easy to use based on several sample schemes provided.


Elastic data, introduced in Coherence 3.7, allows for the use of solid state devices, most typically flash drives, to provide spill over capacity for a cache. Using Elastic data, a cache is specified to use a specific type of backing map based on a RAM or DISK journal. After it is defined, the cache can support massive amounts of data per node, often as much as 100GB. Elastic data has been extensively tested and is proven to have almost no performance difference with totally RAM-based solutions. Additionally, elastic data is simple to configure, in the base case a caching scheme need only specify that the backing map be RAM journal based. However, a variety of configuration options exist for specifying how much memory to use for the backing map, what device to use, and others.


The simplest form of an elastic cache is based on the RAM journal which can be added to the backing-map-scheme element to define an elastic data-based cache. When memory is exceeded, the RAM journal automatically delegates to a flash journal. Specifying a FLASH journal results in the imediate use of a journal files rather than being based on running out of memory as is the case with a RAM journal.

Both flash journals and RAM journals can be controlled using command-line arguments and override files. The most common override is the size of the journal itself, typically some percentage of heap. However, a variety of other values can be controlled, such as how large a value to keep in memory, what directory to use for storage, and similar variables.



Documents

Coherence 3.7 New Features Overview - Oracle