Oracle Coherence is a distributed data grid solution, keeping data available in memory, and using sophisticated distribution algorithms and protocols to synchronize and transfer information between its nodes. This model gives us amazing access times by having data readily available and improved reliability by distributing the data between several instances and machines, adding redundancy to avoid loss of information.
The most recent version of WebLogic, 12.1.2, comes with the newest Coherence version, also numbered 12.1.2, and tighter integration between the two products; Coherence is now enabled by default at the server's classpath, working as a regular subsystem like JMS, for instance.
Also, we are able to create and configure Coherence clusters from the administration console (and related technologies such as JMX and WLST). Finally, there's a new deployment package, Grid ARchive (GAR), that encapsulates Coherence configuration files, for instance, cache declarations and operational parameters, into a consistent unit, making administrative tasks more streamlined.
For more details on this, check out the documentation at http://docs.oracle.com/middleware/1212/wls/WLCOH/create-application.htm.
As you may recall, we configured the web applications to use in-memory HTTP Session replication when configuring a WebLogic cluster. Another alternative for session replication on WebLogic is to use Coherence*Web. This module enables WebLogic session data to be distributed (replicated) among multiple machines, which is basically the same functionality provided by the in-memory session replication feature, but using Coherence as the engine. This allows different applications and even servers to access session data, and, as we can configure standalone Coherence servers to be part of a cluster (each running on their own JVM instance), the application server heap space isn't cluttered with session data.
Coherence*Web can be used with several other application servers, such as Oracle Glassfish and Apache Tomcat among others. For a complete list of benefits and the possibilities of Coherence*Web, check out the product's documentation at http://docs.oracle.com/middleware/1212/coherence/COHCW/start.htm.
We are going to configure an in-process topology for Coherence*Web, meaning that Coherence is going to share the JVM of a WebLogic server, running as its subsystem.
Up to Version 12.1.1, this integration wasn't available out of the box. It was possible to set it up, but the process involved copying libraries around. Now, coherence.jar
and coherence-web.jar
(the files that enable Coherence*Web) are loaded by default at server startup, making the configuration process easier.
To use this feature, we need to enable a Coherence cluster, configure a WebLogic instance to be Coherence's data repository, and, finally, we must adjust the web application that will use this mechanism.
To show how to use Coherence*Web, we're going to use the default cluster configuration provided by Coherence.
Using the default configuration is a great way to get up and running quickly, but keep in mind that for real-world systems this is not an option; aspects like environment isolation and network latency must be addressed by specific configurations. You can find more information about the parameters available by checking the official documentation at http://docs.oracle.com/cd/E24290_01/coh.371/e22837/cluster_setup.htm.
These are the steps to add a Coherence cluster to the domain:
sessionDataCluster
in the Name field and then click on Next.Another change introduced by Version 12.1.2 is that every WebLogic Server is now potentially also a Coherence node; as the libraries are enabled at the server's classpath, all we have to do to start using Coherence is to add a server to a Coherence cluster.
The most important configuration associated with this step is deciding if that specific server will hold data in it or if it will act as a client in relation to data; in other words, we have to decide if the instance will have local storage enabled. Also, there's a specific Coherence*Web parameter that indicates if the node will act as a storage tier for this feature.
When a server is added to a Coherence cluster, local storage is enabled by default and Coherence*Web storage isn't. To edit Coherence-related parameters of a specific server, the following steps must be followed:
Now that we already have a server configured to store session data, we need to modify the application deployment descriptors and change the actual HTTP session state replication mechanism to use Coherence*Web:
weblogic.xml
under /WebContent/WEB-INF
in the project Store.persistent-store-type
to coherence-web
to instruct WebLogic to use Coherence*Web and add a new tag, coherence-cluster-ref
, to reference the cluster we created in the previous section.<wls:session-descriptor> <wls:persistent-store-type> coherence-web </wls:persistent-store-type> </wls:session-descriptor> <wls:coherence-cluster-ref> <wls:coherence-cluster-name> sessionDataCluster </wls:coherence-cluster-name> </wls:coherence-cluster-ref>
In order to test that your sessions are now stored on an external cache server, put some information on the session, shutdown one or both Managed Servers, and start them again. Since the data persists outside these servers, the cache kept the data, even though the application went down.
Due to the resource limitations of a normal developer workstation or laptop (physical memory, basically), the example used only one node to hold session data. On a production system, or when the memory or number of servers aren't constraints, you can follow the same procedures to scale the cache to use multiple nodes, giving it better performance and increased reliability. As Coherence's is naturally a distributed data grid, having more nodes will contribute to the overall experience.
TopLink Grid is a feature that enables Java Persistence API (JPA) to use Coherence to cache object instances, bringing performance gains to an application.
As you may remember, TopLink is WebLogic's JPA implementation, so enabling this cache function basically involves deciding which kind of caching is a best fit for the business scenario and configuring it.
There are a few different strategies that can be used when attaching Coherence to the JPA layer. Here's a quick description of each one:
If you want to read details about each topology, check out the following document: http://docs.oracle.com/middleware/1212/coherence/COHIG/tlg_integrate.htm.
The following figure shows how such a configuration would work; Coherence would be at the front of the database, intercepting and serving requests from or to it.
Since this is considered an advanced feature of a more complex WebLogic topology, the configuration of such features is out of the scope of this book, but at the following URL you can find documentation and step-by-step instructions on how to enable it: http://docs.oracle.com/cd/E24290_01/coh.371/e23131/toc.htm.
This integration between JPA and Coherence is a powerful feature when scaling up your application, but keep in mind that a new set of considerations must be taken, such as how many Coherence instances must be set up, how to distribute the load over them, for how long a specific object must be kept in the cache, how to invalidate it, and so on.