The current release of WebLogic Server includes features that allow deployed applications to easily use Coherence data caches. These features allow WebLogic Server to seamlessly incorporate Coherence*Web for session management and TopLink Grid as an object-to-relational persistence framework. Collectively, these features are referred to as ActiveCache. ActiveCache is employed by applications running on WebLogic Server, and combines the following functionality of Coherence clusters, Coherence*Web, and TopLink Grid:
Reliably stores and distributes serializable Java Objects.
ActiveCache is fully compatible with the Coherence*Web HTTP Session Management Module. Coherence*Web allows the data cache to enable WebLogic Server memory resources.
The addition of TopLink Grid gives ActiveCache the ability to scale out JPA applications.
Manages the life cycle of stored objects.
Provides serialization options which reduce heap requirements and the computational cost of deserializing session state each time it is accessed.
Dynamically repartitions data, enabling optimal data distribution.
Provides near caching, which keeps frequently read data on the heap.
Provides direct access by applications to data caches. Applications that run on WebLogic Server can use either resource injection or component-based JNDI lookup to directly access data caches.
Configure Coherence Cluster attributes using the WebLogic Server Administration Console and WLST.
Monitor cluster-related properties from the WebLogic Server Administration Console. For example, you can use the Administration Console to monitor the cluster size, names and identifiers of cluster members, the license mode, and the cluster version.
ActiveCache provides replicated and distributed caching services that can make an application's data available to all servers in a Coherence data cluster.
ActiveCache gives applications running on WebLogic Server the ability to directly access Coherence data caches. The addition of Coherence data clusters to WebLogic Server instances enables you to create a data tier dedicated to caching application data and storing replicated session state. This is separate from the application tier—the WebLogic Server instances dedicated to running the application. ActiveCache technology allows the application tier to efficiently communicate with the data tier and cache data in it.
See Chapter 3, "Developing Applications for ActiveCache" for more information.
ActiveCache can be employed for several different combinations of application and data tiers, or cluster topologies. For example, one topology is where all WebLogic Server instances employing Coherence (also known as Coherence nodes) are configured to store data. The applications and the data caches are collocated, and there is no separate data tier. Each Coherence node can serve requests and cache data.
Another possible topology is where there is a mixture of storage-enabled and storage-disabled ActiveCache nodes. In this topology, the storage-enabled nodes act as a data tier, while the storage-disabled nodes run the applications and serve requests. This topology creates a separate data tier which is isolated from non-cache application faults. All of the nodes in this topology can also be managed and monitored by WebLogic Server tools.
A third topology consists of storage-disabled WebLogic Server nodes and stand-alone Coherence caches. This topology also creates a separate data tier which is isolated from non-cache application faults. However, unlike the first two topologies, the data caches do not incur any costs related to the ActiveCache nodes' use of heap or server startup time.
Applications using ActiveCache can easily access the data cache. ActiveCache provides a @Resource annotation that allows a Coherence NamedCache cache object to be identified and dynamically injected into a servlet or EJB. As an alternative to resource injection, applications using ActiveCache can use a component-based JNDI tree to look up the NamedCache.
Cache services are classloader-scoped, and can be visible at an application server scope: caches will be visible globally to all applications deployed on the server, EAR scope: caches will be visible to all modules in the EAR, or WAR scope: caches will be visible to the individual modules only.
Scoping is determined by where you store the cache configuration file. The cache configuration file is where you define the cache object and cache types, then map cache names and name patterns to the cache types.
Like the cache configuration, cluster nodes are also classloader-scoped. Scoping is determined by where you store the coherence.jar and active-cache.jar files. Like cache services, cluster nodes can be application server-scoped: the entire JVM acts as a single Coherence cluster node, EAR-scoped: each application can be a Coherence cluster node, or WAR-scoped: each Web module within an application can be a Coherence cluster node.
ActiveCache enables you to display cluster-related properties in the WebLogic Server Administration Console. You can configure or reset some of these properties by using the Administration Console, WLST, or by importing a tangosol-coherence-override.xml configuration file.
See Chapter 4, "Enabling State Session Persistence" for more information.
The addition of Coherence*Web to ActiveCache enables you to provide Coherence cluster-based HTTP session state persistence to applications running on WebLogic Server. Coherence*Web enables HTTP session sharing and management across different Web applications, domains and heterogeneous application servers. Session data can be stored in data caches outside of the application server, thus freeing application server heap space and enabling server restarts without losing session data.
See the User's Guide for Oracle Coherence*Web for information on using Coherence*Web with WebLogic Server applications.
TopLink Grid's relational-to-object mapping capabilities allow ActiveCache to cache relational data. The Coherence data caches can cache copies of database queries and result sets. With this feature, database access occurs only when no cached copy of the required data is available in the data cache, or when the application performs a create, update, or delete operation that must be persisted to the database. This added optimization provides improved scalability and performance to the system.
TopLink Grid allows JPA Entity caching. This lets you support very large, shared grid caches that span cluster nodes. Calls for Entities cached in ActiveCache result in a get on the associated data cache. If the data cache does not contain the object, then the database is queried.
TopLink Grid enables you to direct queries to ActiveCache. If the desired query result is not found in the cache, it can be read from the database and then placed in the cache, making it available for subsequent queries. ActiveCache's ability to manage very large numbers of objects increases the likelihood of a result found in the cache, as reads in one cluster member become immediately available to others.
Writing Entities to the database is also made possible by TopLink Grid. Applications can directly write Entities to the database, then put them into the data cache (so that it reflects the database state), or put Entities into the data cache, then have the data cache write them to the database.
See Chapter 5, "Accessing and Retrieving Relational Data" for more information.