+ ![]()
+
+ Coherence CDI provides support for CDI (Contexts and Dependency Injection) within Coherence cluster members.
+ +It allows you both to inject Coherence-managed resources, such as NamedCache and Session instances into CDI managed beans, and to inject CDI beans into Coherence-managed resources, such as event interceptors and cache stores, and to handle Coherence server-side events using CDI observer methods.
In addition, Coherence CDI provides support for automatic injection of transient objects upon deserialization. +This allows you to inject CDI managed beans such as services and repositories (to use DDD nomenclature) into transient objects, such as entry processor and even data class instances, greatly simplifying implementation of true Domain Driven applications.
+ +In order to use Coherence CDI, you need to declare it as a dependency in your pom.xml:
Once the necessary dependency is in place, you can start using CDI to inject Coherence objects into managed CDI beans, and vice versa, as the following sections describe.
+ +NamedCache and related objects
NamedTopic and related objects
<←cluster—and—operationalcontext—injection,Cluster and OperationalContext Injection>>
<←configurablecachefactory—and—session—injection,ConfigurableCacheFactory and Session Injection>>
<←serializer—injection,Serializer Injection>>
Injectable
CDI, and dependency injection in general, make it easy for application classes to declare the dependencies they need and let the runtime provide them when necessary. +This makes the applications easier to develop, test and reason about, and the code significantly cleaner.
+ +Coherence CDI allows you to do the same for Coherence objects, such as Cluster, Session, NamedCache, ContinuousQueryCache, ConfigurableCacheFactory, etc.
NamedCache and related objectsIn order to inject an instance of a NamedCache into your CDI bean, you simply need to define an injection point for it:
In the example above we’ve assumed that the cache name you want to inject is the same as the name of the field you are injecting into, people.
+If that’s not the case, you can use @Cache qualifier to specify the name of the cache you want to obtain explicitly:
This is also what you have to do if you are using constructor injection instead:
+ +All of the examples above assume that you want to use the default ConfigurableCacheFactory, which is often, but not always the case.
+For example, you may have an Extend client that connects to multiple Coherence clusters, in which case you would have multiple Coherence cache config files, and multiple ConfigurableCacheFactoriy instances.
In this case you would use @CacheFactory qualifier to specify the URI of the cache configuration to use:
You can replace NamedCache in any of the examples above with AsyncNamedCache in order to inject asynchronous variant of the NamedCache API:
You can also inject cache views, which are effectively instances of a ContinuousQueryCache, either by declaring the injection point as ContinuousQueryCache instead of NamedCache, or by simply adding @CacheView qualifier:
The examples above are equivalent, and both will bring all the data from the backing cache into a local view, as they will use AlwaysFilter when constructing CQC.
+If you want to limit the data in the view to a subset, you can implement a custom @WhereFilter for convenience, which allows you to specify a filter using CohQL:
The ContinuousQueryCache, and cache views by extension, also support transformation of the cached value on the server, in order to reduce both the amount of data stored locally and the amount of data transferred over the network.
+For example, you may have a complex Person objects in the backing cache, but only need their names in order to populate a drop down on the client UI.
In that case, you can implement a custom @PropertyExtractor for convenience:
Note that the value type in the example above has changed from Person to String, due to server-side transformation caused by the specified @PropertyExtractor.
NamedTopic and related objectsIn order to inject an instance of a NamedTopic into your CDI bean, you simply need to define an injection point for it:
In the example above we’ve assumed that the topic name you want to inject is the same as the name of the field you are injecting into, in this caseorders.
+If that’s not the case, you can use @Topic qualifier to specify the name of the cache you want to obtain explicitly:
This is also what you have to do if you are using constructor injection instead:
+ +All of the examples above assume that you want to use the default ConfigurableCacheFactory, which is often, but not always the case.
+For example, you may have an Extend client that connects to multiple Coherence clusters, in which case you would have multiple Coherence cache config files, and multiple ConfigurableCacheFactoriy instances.
In this case you would use @CacheFactory qualifier to specify the URI of the cache configuration to use:
The examples above allow you to inject a NamedTopic instance into your CDI bean, but it is often simpler and more convenient to inject Publisher or Subscriber for a given topic instead.
This can be easily accomplished by replacing NamedTopic<T> in any of the examples above with either Publisher<T>:
or Subscriber<T>:
Basically, all topic-related details, such as topic name (based on either injection point name or the explicit name from @Topic annotation), cache factory URI and message type, will be used under the hood to retrieve the NamedTopic, and to obtain Publisher or Subscriber from it.
Additionally, if you want to place your Subscribers into a subscriber group, you can easily accomplish that by adding @SubscriberGroup qualifier to the injection point:
While the injection of a NamedCache, NamedTopic, and related instances, as shown above, is probably the single most useful feature of Coherence CDI, it is certainly not the only one.
+The following sections describe other Coherence artifacts that can be injected using Coherence CDI.
Cluster and OperationalContext InjectionIf you need an instance of a Cluster interface somewhere in your application, you can easily obtain it via injection:
You can do the same if you need an instance of an OperationalContext:
ConfigurableCacheFactory and Session InjectionOn rare occasions when you need to use either of these directly, Coherence CDI makes it trivial to do so.
+ +To obtain an instance of a default CCF or Session, all you need to do is inject them into the class that needs to use them:
If you need a specific CCF or Session you can simply qualify them using @CacheFactory qualifier and specifying the URI of the cache config file to use:
Serializer InjectionWhile in most cases you won’t have to deal with serializers directly, Coherence CDI makes it simple to obtain named serializers (and to register new ones) when you need.
+ +To get a default Serializer for the current context class loader, you can simply inject it:
However, it may be more useful to inject one of the named serializers defined in the operational configuration, which can be easily accomplished using @SerializerFormat qualifier:
In addition to the serializers defined in the operational config, the example above will also perform BeanManager lookup for a named bean that implements Serializer interface.
That means that if you implemented a custom Serializer bean, such as:
it would be automatically discovered and registered by the CDI, and you would then be able to inject it just as easily as the named serializers defined in the operational config:
+ +Coherence has a number of server-side extension points, which allow users to customize application behavior in different ways, typically by configuring their extensions within various sections of the cache configuration file. +For example, the users can implement event interceptors and cache stores, in order to handle server-side events and integrate with the external data stores and other services.
+ +Coherence CDI provides a way to inject named CDI beans into these extension points using custom configuration namespace handler.
+ +Once you’ve declared the handler for the cdi namespace above, you can specify <cdi:bean> element in any place where you would normally use <class-name> or <class-factory-name> elements:
Note that you can only inject named CDI beans (beans with an explicit @Named annotations) via <cdi:bean> element.
+For example, the cacheListener interceptor bean used above would look similar to this:
Also keep in mind that only @ApplicationScoped beans can be injected, which implies that they may be shared.
+For example, because we’ve used wildcard * as a cache name within the cache mapping in the example above, the same instance of cacheListener will receive events from multiple caches.
This is typically fine, as the event itself provides the details about the context that raised it, including cache name and the service it was raised from, but it does imply that any shared state that you may have within your listener class shouldn’t be context-specific and it must be safe for concurrent access from multiple threads.
+If you can’t guarantee the latter, you may want to declare the onEvent method as synchronized, to ensure only one thread at a time can access any shared state you may have.
While the above examples show that you can implement any Coherence EventInterceptor as a CDI bean and register it using <cdi:bean> element within the cache configuration file, Coherence CDI also provides a much simpler way to accomplish the same goal using standard CDI Events and Observers.
The first thing you need to do is register a single global interceptor within the cache config:
+ +Coherence CDI EventDispatcher bean will then listen to all events raised by all Coherence event dispatchers and re-raise them as CDI events that you can observe.
+For example, to implement the equivalent of cacheListener interceptor above, you would simply define an observer method in any CDI bean that wants to be notified when the event happens:
The observer method above will receive all INSERTING events for all the caches, across all the services, but you can use CDI qualifiers to control that behavior:
Of course, you can also remove qualifiers to broaden the scope of events your handler receives:
+ +The examples above show only how to handle EntryEvents, but the same applies to all other event types:
And again, you can broaden the scope by widening the type of events you observe:
+ +All of the examples above used synchronous observers by specifying @Observes qualifier for each observer method.
+However, Coherence CDI fully supports asynchronous CDI observers as well.
+All you need to do is replace @Observes with @ObservesAsync in any of the examples above.
However, there is an important caveat.
+ +Coherence events fall into two categories: pre- and post-commit events.
+All of the events whose name ends with ing, such as Inserting, Updating, Removing or Executing are pre-commit, which means that they can either modify the data or even completely cancel the operation by throwing an exception, but in order to do so they must be synchronous to ensure that they are executed on the same thread that is executing the operation that triggered the event.
That means that you can observe them using asynchronous CDI observers, but if you want to mutate the set of entries that are part of the event payload, or veto the event by throwing an exception, you must use synchronous CDI observer.
+ +Using CDI to inject Coherence objects into your application classes, and CDI beans into Coherence-managed objects will allow you to support many use cases where dependency injection may be useful, but it doesn’t cover an important use case that is somewhat specific to Coherence.
+ +Coherence is a distributed system, and it uses serialization in order to send both the data and the processing requests from one cluster member (or remote client) to another, as well as to store data, both in memory and on disk.
+ +Processing requests, such as entry processors and aggregators, are then deserialized on a target cluster member(s) in order to be executed, and in some cases they could benefit from dependency injection in order to avoid service lookups.
+ +Similarly, while the data is stored in a serialized, binary format, it may need to be deserialized into user supplied classes for server-side processing, such as when executing entry processors and aggregators, and can also benefit from dependency injection (in order to support Domain-Driven Design (DDD), for example).
+ +While these transient objects are not managed by the CDI container, Coherence CDI does support their injection after deserialization, but for performance reasons requires that you explicitly opt-in by implementing com.oracle.coherence.cdi.Injectable interface.
InjectableWhile not technically a true marker interface, Injectable can be treated as such for all intents and purposes.
+All you need to do is add it to the implements clause of your class in order for injection on deserialization to kick in:
Assuming that you have the following Converter service implementation in your application, it will be injected into InjectableBean after deserialization and the getConvertedText method will return the value of the text field converted to upper case:
If your Injectable class has @PostConstruct callback method, it will be called after the injection.
+However, because we have no control over object’s lifecycle after that point, @PreDestroy callback will never be called).
You should note that the above functionality is not dependent on the serialization format and will work with both Java and POF serialization (or any other custom serializer), and for any object that is deserialized on any Coherence member (or even on a remote client).
+ +While the deserialized transient objects are not true CDI managed beans, being able to inject CDI managed dependencies into them upon deserialization will likely satisfy most dependency injection requirements you will ever have in those application components. +We hope you’ll find it useful.
+ +This module builds an example Coherence OCI compatible image.
+ +The image built in this module is a demo and example of how to build a Coherence image using +the JIB Maven Plugin. +The image is not intended to be used in production deployments or as a base image, it is specifically +for demos, experimentation and learning purposes.
+The Coherence image uses a distroless base image containing OpenJDK. +There are many advantages of a distroless image, security being the main one. +Of course, you are free to use whatever base image or build mechanism you want for your own images.
+ +The image built by the coherence-docker module contains the following Coherence components:
| Component | +Description | +
|---|---|
| Coherence | +The core Coherence server | +
| Coherence Extend | +A Coherence*Extend proxy, exposed on port 20000 |
+
| Coherence Management | +Coherence Management over REST, exposed on port 30000 |
+
| Coherence Metrics | +Coherence Metrics, exposed on port 9612 |
+
| Coherence Tracing | +Coherence tracing is configured to use a Jaeger tracing server. See the |
+
Assuming that you have first cloned the Coherence CE project the to build the Coherence image run the following command
+from the top-level Maven prj/ folder:
The name of the image produced comes from properties in the coherence-docker module pom.xml file.
${docker.registry}/coherence-ce:<version>
Where <version> is the version of the product from the pom.xml file.
+The ${docker.registry} property is the name of the registry that the image will be published to, by default
+this is oraclecoherence.
So, if the version in the pom.xml is 14.1.1-0-20 the image produced will be
+oraclecoherence/coherence-ce:14.1.1-0-20
To change the registry name the image can be built by specifying the docker.registry property, for example:
The example above would build an image named foo/coherence:14.1.1-0-20
Run the image just like any other image. In Docker this command would be:
+ +The -P parameter will ensure that the Extend, gRPC, management and metrics ports will all be exposed.
This image can be run in Kubernetes using the Coherence Operator.
+ +The sections below on additional configurations do not apply when using the Coherence Operator to run the image +in Kubernetes. The operator provides functionality to configure the container correctly.
+Many options in Coherence can be set from System properties prefiexed with coherence..
+The issue here is that System properties are not very easy to pass into the JVM in the container, whereas environment
+variables are. To help with this the main class which runs in the container will convert any environment variable
+prefixed with coherence. into a System property before it starts Coherence.
The example above sets two environment variables, coherence.cluster=testing and coherence.role=storage.
+These will be converted to System properties so Coherence will start the same as it would if the variables
+had been passed to the JVM command line as -Dcoherence.cluster=testing -Dcoherence.role=storage
This only applies to environment variables prefixed with coherence. that have not already set as System
+properties some other way.
Images built with JIB have a fixed entrypoint configured to run the application. This is not very flexible if additional
+options need to be passed to the JVM. The Coherence image makes use of the JVM’s ability to load options at start-up
+from a file by using a JVM option @<file-name>. The Coherence image entrypoint contains @/args/jvm-args.txt, so the
+JVM will load additional options on start-up from a file named /args/jvm-args.txt. This means that additional
+options can be provided by adding a volume mapping that adds this file to the container.
For example, to set the heap to 5g, the Coherence cluster name to test-cluster and role name to storage then
+additional JVM arguments will be required. Create a file named jvm-args.txt containing these properties:
If the file has been created in a local directory named /home/oracle/test-args then the image can be run with the following
+command:
This will cause Docker to mount the local /home/oracle/test-args directory to the /args directory in the container
+where the JVM will find the jvm-args.txt file.
Images built with JIB have a fixed classpath configured, which is not very flexible if additional resources need to be +added to the classpath. The Coherence image maps two additional directories to the classpath that are empty in the image +and may be used to add items to the classpath by mapping external volumes to these directories.
+ +The additional classpath entries are:
+ +/coherence/ext/lib/* - this will add all .jar files under the /coherence/ext/lib/ directory to the classpath
/coherence/ext/conf - this adds /coherence/ext/conf to the classpath so that any classes, packages or other
+resource files in this directory will be added to the classpath.
For example:
+ +On the local Docker host there is a folder called /dev/my-app/lib that contains .jar files to be added to the
+container classpath.
The command above maps the local directory /dev/my-app/lib to the /coherence/ext/lib in the container so that any
+.jar files in the /dev/my-app/lib directory will now be on the Coherence JVM’s classpath.
On the local Docker host there is a folder called /dev/my-app/classes that contains .class files and other
+application resources to be added to the container classpath.
The command above maps the local directory /dev/my-app/classes to the /coherence/ext/conf in the container so that
+any classes and resource files in the /dev/my-app/classes directory will now be on the Coherence JVM’s classpath.
Multiple containers can be started to form a cluster. By default, Coherence uses multi-cast for cluster discovery but +in containers this either will not work, or is not reliable, so well-known-addressing can be used.
+ +This example is going to use basic Docker commands and links between containers. +There are other ways to achieve the same sort of functionality depending on the network configurations you want to +use in Docker.
+ +First, determine the name to be used for the first container, in this example it will be storage-1.
Next, create a ` +Start the first container in the cluster:
+ +The first container has been started with a container name of storage-1, and the host name also set to storage-1.
+The container sets the WKA host name to storage-1 using -e coherence.wka=storage-1 (this will be converted to the
+System property coherence.wka=storage-1 see testing using -e coherence.cluster=testing (this will be converted
+to the System property coherence.cluster=testing see
The important part here is that the container has a name, and the --hostname option has also been set.
+This will allow the subsequent cluster members to find this container.
Now, subsequent containers can be started using the same cluster name and WKA host name, but with different container +names and a link to the first container, all the containers will form a single Coherence cluster:
+ +Two more containers, storage-2 and storage-3 will now be part of the cluster.
All the members must have a --link option to the first container and have the same WKA and cluster name properties.
The Coherence image comes with tracing already configured, it just requires a suitable Jaeger server to send spans to.
+ +The simplest way to start is deploy the Jaeger all-in-one server, for example:
+ +The Jaeger UI will be available to browse to at http://127.0.0.1:16686
+ +Jaeger has been started with a container name of jaeger, so it will be discoverable using that host name by the Coherence
+containers. Start the Coherence container with a link to the Jaeger container and set the JAEGER_AGENT_HOST
+environment variable to jaeger:
Once the Coherence container is running perform some interations with it using one of the exposed services, i.e Extend
+or gRPC, and spans will be sent to the Jaeger collector and will be visible in the UI by querying for the coherence
+service name. The service name used can be changed by setting the JAEGER_SERVICE_NAME environment variable when
+starting the container, for example:
Spans will now be sent to Jaeger with the service name coherence-test.
Tracing is very useful to show what happens under the covers for a given Coherence API call. Traces are more interesting
+when they come from a Coherence cluster with multiple members, where the traces span different cluster members.
+This can easily be done by running multiple containers with tracing enabled and configuring
Coherence provides a number of additional modules that provide support for different Microprofile APIs.
+ +Using Coherence as a Microprofile config source.
+Configure Coherence to publish metrics via the Microprofile metrics API.
+Coherence MP Config provides support for [Eclipse MicroProfile Config] (https://microprofile.io/project/eclipse/microprofile-config) within Coherence cluster members.
+ +It allows you both to configure various Coherence parameters from the values specified in any of the supported config sources, and to use Coherence cache as another, mutable config source.
+ +In order to use Coherence MP Config, you need to declare it as a dependency in your pom.xml:
You will also need an implementation of the Eclipse MP Config specification as a dependency.
+For example, if you are using Helidon, add the following to your pom.xml:
Coherence provides a number of configuration properties that can be specified by the users in order to define certain attributes or to customize cluster member behavior at runtime. +For example, attributes such as cluster and role name, as well as whether a cluster member should or should not store data, can be specified via system properties:
+ +-Dcoherence.cluster=MyCluster -Dcoherence.role=Proxy -Dcoherence.distributed.localstorage=false+
Most of these attributes can also be defined within the operational or cache configuration file.
+ +For example, you could define first two attributes, cluster name and role, within the operational config override file:
+ +While these two options are more than enough in most cases, there are some issues with them being the only way to configure Coherence:
+ +Unfortunately, neither of the two use cases above is supported out of the box, but that’s the gap Coherence MP Config is designed to fill.
+ +As long as you have coherence-mp-config and an implementation of Eclipse MP Config specification to your class path, Coherence will use any of the standard or custom config sources to resolve various configuration options it understands.
Standard config sources in MP Config include META-INF/microprofile-config.properties file, if present in the class path, environment variables, and system properties (in that order, with the properties in the latter overriding the ones from the former).
+That will directly address problem #2 above, and allow you to specify Coherence configuration options via environment variables within Kubernetes YAML files, for example:
Of course, the above is just an example — if you are running your Coherence cluster in Kubernetes, you should really be using Coherence Operator instead, as it will make both the configuration and the operation of your Coherence cluster much easier.
+ +You will also be able to specify Coherence configuration properties along with the other configuration properties of your application, which will allow you to keep everything in one place, and not scattered across many files.
+For example, if you are writing a Helidon application, you can simply add coherence section to your application.yaml:
Coherence MP Config also provides an implementation of Eclipse MP Config ConfigSource interface, which allows you to store configuration parameters in a Coherence cache.
This has several benefits:
+ +While the features above give you incredible amount of flexibility, we also understand that such flexibility is not always desired, and the feature is disabled by default.
+ +If you want to enable it, you need to do so explicitly, by registering CoherenceConfigSource as a global interceptor in your cache configuration file:
Once you do that, CoherenceConfigSource will be activated as soon as your cache factory is initialized, and injected into the list of available config sources for your application to use via standard MP Config APIs.
By default, it will be configured with a priority (ordinal) of 500, making it higher priority than all the standard config sources, thus allowing you to override the values provided via config files, environment variables and system properties.
+However, you have full control over that behavior and can specify different ordinal via coherence.mp.config.source.ordinal configuration property.
Coherence MP Metrics provides support for [Eclipse MicroProfile Metrics] (https://microprofile.io/project/eclipse/microprofile-metrics) within Coherence cluster members.
+ +This is a very simple module that allows you to publish Coherence metrics into MicroProfile Metric Registries available at runtime, and adds Coherence-specific tags to all the metrics published within the process, in order to distinguish them on the monitoring server, such as Prometheus.
+ +In order to use Coherence MP Metrics, you need to declare it as a dependency in your pom.xml:
That’s it — once the module above is in the class path, Coherence will discover MpMetricRegistryAdapter service it provides, and use it to publish all standard Coherence metrics to the vendor registry, and any user-defined application metrics to the application registry.
All the metrics will be published as gauges, because they represent point-in-time values of various MBean attributes.
+ +There could be hundreds of members in a Coherence cluster, with each member publishing potentially the same set of metrics. +There could also be many Coherence clusters in the environment, possibly publishing to the same monitoring server instance.
+ +In order to distinguish metrics coming from different clusters, as well as from different members of the same cluster, Coherence MP Metrics will automatically add several tags to ALL the metrics published within the process.
+ +The tags added are:
+ + +| Tag Name | +Tag Value | +
|---|---|
cluster |
+the cluster name | +
site |
+the site the member belongs to (if set) | +
machine |
+the machine member is on (if set) | +
member |
+the name of the member (if set) | +
node_id |
+the node ID of the member | +
role |
+the member’s role | +
This ensures that the metrics published by one member do not collide with and overwrite the metrics published by another members, and allows you to query and aggregate metrics based on the values of the tags above if desired.
+ +This is the module that builds the Coherence documentation. +The module is not part of the default build and must be built separately.
+ + +To build the docs, run the following Maven command from the top-level prj/ directory:
To view the documentation after building it, run the following command from the top-level prj/ directory:
The installation requires you to install Python, which runs a small Pythin http server from the directory where the docs +are built.
+Coherence is scalable, fault-tolerant, cloud-ready, distributed platform for building grid-based applications and reliably +storing data. The product is used at scale, for both compute and raw storage, in a vast array of industries such as +critical financial trading systems, high performance telecommunication products, and eCommerce applications.
+ +Typically, these deployments do not tolerate any downtime and Coherence is chosen due its novel features in death +detection, application data evolvability, and the robust, battle-hardened core of the product that enables it to be +seamlessly deployed and adapted within any ecosystem.
+ +At a high level, Coherence provides an implementation of the familiar Map<K,V> interface but rather than storing +the associated data in the local process, it is partitioned (or sharded) across a number of designated remote +nodes. This partitioning enables applications to not only distribute (and therefore scale) their storage across multiple processes, +machines, racks, and data centers, but also to perform grid-based processing to truly harness the CPU resources of the +machines.
+ +The Coherence interface 'NamedCache<K,V>' (an extension of 'Map<K,V>' provides methods to query, aggregate +(map/reduce style), and compute (send functions to storage nodes for locally executed mutations) the data set. +These capabilities, in addition to numerous other features, enable Coherence to be used as a framework to write robust, +distributed applications.
+ +What is Oracle Coherence?
+A quick-start guide to using Coherence.
+Oracle Coherence commercial edition product documentation.
+Browse the Coherence CE API Docs.
+Example Coherence OCI container (Docker) images.
+First and foremost, Coherence provides a fundamental service that is responsible for all facets of clustering and is a +common denominator / building block for all other Coherence services. +This service, referred to as 'service 0' internally, ensures that the mesh of members is maintained and responsive, +taking action to collaboratively evict, shun, or in some cases, voluntarily depart the cluster when deemed necessary. +As members join and leave the cluster, other Coherence services are notified, thus enabling those services to react accordingly.
+ +This part of the Coherence product has been in production for more than 10 years, being the subject of some extensive and +imaginative testing. +While this feature has been discussed here, it certainly is not something that customers, generally, interact with directly, but is +important to be aware of.
+Coherence services build on top of the clustering service. The key implementations to be aware of are PartitionedService, InvocationService, and ProxyService.
+ +In the majority of cases, customers will deal with caches;
+a cache is represented by an implementation of NamedCache<K,V>.
+Cache is an unfortunate name, as many Coherence customers use Coherence as a system-of-record rather than a lossy store of data.
+A cache is hosted by a service, generally the PartitionedService, and is the entry point to store, retrieve, aggregate, query, and stream data.
Caches provide a number of features:
+ +Fundamental key-based access: get/put getAll/putAll.
+ +Client-side and storage-side events:
+MapListeners to asynchronously notify clients of changes to data.
+ +EventInterceptors (either sync or async) to notify storage level events, including mutations, partition transfer, failover, and so on.
+ +NearCaches - Locally cached data based on previous requests with local content invalidated upon changes in the storage tier.
+ +ViewCaches - Locally stored view of remote data that can be a subset based on a predicate and is kept in sync, real time.
+ +Queries - Distributed, parallel query evaluation to return matching key, values, or entries with potential to optimize performance with indices.
+ +Aggregations - A map/reduce style aggregation where data is aggregated in parallel on all storage nodes, and results streamed back to the client for aggregation of those results to produce a final result.
+ +Data local processing - Ability to send a function to the relevant storage node to execute processing logic for the appropriate entries with exclusive access.
+ +Partition local transactions - Ability to perform scalable transactions by associating data (thus being on the same partition) and manipulating other entries on the same partition, potentially across caches.
+ +Non-blocking / async NamedCache API
+ +C++ and .NET clients - Access the same NamedCache API from either C++ or .NET.
+ +Portable Object Format - Optimized serialization format, with the ability to navigate the serialized form for optimized queries, aggregations, or data processing.
+ +Integration with Databases - Database and third party data integration with CacheStores, including synchronous or asynchronous writes.
+ +CohQL - Ansi-style query language with a console for adhoc queries.
+ +Topics - Distributed topics implementation that offers pub/sub messaging with the storage capacity, the cluster, and parallelizable subscribers.
+ +Coherence also provides a number of non-functional features:
+ +Rock solid clustering - Highly tuned and robust clustering stack that enables Coherence to scale to thousands of members in a cluster with thousands of partitions and terabytes of data being accessed, mutated, queried, and aggregated concurrently
+ +Safety first - Resilient data management that ensures backup copies are on distinct machines, racks, or sites, and the ability to maintain multiple backups.
+ +24/7 Availability - Zero downtime with rolling redeployment of cluster members to upgrade application or product versions.
+Backward and forward compatibility of product upgrades, including major versions.
+ +Persistent Caches - Ability to use local file system persistence (thus avoid extra network hops) and leverage Coherence consensus protocols to perform distributed disk recovery when appropriate.
+ +Distributed State Snapshot - Ability to perform distributed point-in-time snapshot of cluster state, and recover snapshot in this or a different cluster (leverages persistence feature).
+ +Lossy redundancy - Ability to reduce the redundancy guarantee by making backups and/or persistence asynchronous from a client perspective.
+ +Single Mangement View - Provides insight into the cluster with a single JMX server that provides a view of all members of the cluster.
+ +Management over REST - All JMX data and operations can be performed over REST, including cluster wide thread dumps and heapdumps.
+ +Non-cluster Access - Provides access to the cluster from the outside via proxies, for distant (high latency) clients and for non-java languages such as C++ and .NET.
+ +Kubernetes friendly - Enables seemless and safe deployment of applications to k8s with our own operator.
+ +The following Oracle Coherence features are not included in Coherence Community Edition:
+ +Management of Coherence via the Oracle WebLogic Management Framework
+ +WebLogic Server Multitenancy Support
+ +Deployment of Grid Archives (GARs)
+ +HTTP Session Management for Application Servers (Coherence*Web)
+ +GoldenGate HotCache
+ +TopLink-based CacheLoaders and CacheStores
+ +Elastic Data
+ +Federation and WAN (wide area network) Support
+ +Transaction Framework
+ +CommonJ Work Manager
+ +This document details how to quickly get up and running with Coherence.
+ + +As Coherence is generally embedded into an application by using Coherence APIs, +the natural place to consume this dependency is from Maven:
+ +You can also get Coherence from the official Docker image. +For other language clients, use (C++ and +.NET), and for the non-community edition, see Oracle Technology Network.
+ +The following example illustrates the procedure to start a storage enabled Coherence Server, followed by a storage disabled +Coherence Console. +Using the console, data is inserted, retrieved, and then the console is terminated. The console is restarted +and data is once again retrieved to illustrate the permanence of the data.
+ +This example uses the out-of-the-box cache configuration and therefore, explicitly specifying that the console is +storage disabled is unnecessary.
+Coherence cluster members discover each other via one of two mechanisms;
+multicast (default) or Well Known Addressing (deterministic broadcast).
+If your system does not support multicast, enable WKA by specifying -Dcoherence.wka=localhost for both processes
+started in the following console examples.
To run a CohQL console:
+ +To run the Coherence console:
+ +The following example illustrates starting a storage enabled Coherence server, followed by running the HelloCoherence
+application.
+The HelloCoherence application inserts and retrieves data from the Coherence server.
HelloCoherenceHelloCoherence
+