Knowing a little about DC, I wanted to read up further, especially with regard to the cache's behaviour across a multi-node cluster.
Here's a few useful items: -
<snip>
Think of DynaCache as a sophisticated Java™ Hashtable.
The code used to provide the in-memory cache services extends the Java Dictionary class, which is the abstract parent of Hashtable. You configure DynaCache to store objects, and later, based on some data matching rules, DynaCache retrieves those objects and serves them from its cache. Caching rules are stored in a configuration file called cachespec.xml. Single or multiple caches are supported. Caches are stored in the JVM heap memory and DynaCache supports overflow to disk if enabled and when required.
The system administrator has some degree of control over what is placed in memory and what (if anything) overflows to disk via configuration settings. DynaCache also calls a least recently used (LRU) algorithm during the item selection process for memory-based item eviction or overflow. The LRU algorithm consults with a user-specified cache entry priority number before the evictee is chosen. Higher numbered items stay in memory longer.
Disk offload of cache entries from memory occurs when the memory cache fills up or when the server is in the process of performing a normal, administrator-directed shut down and the "FlushToDiskOnStop" property is enabled. Upon a server restart, requests for cache entries are fulfilled by reloading the saved disk data into memory.
The code used to provide the in-memory cache services extends the Java Dictionary class, which is the abstract parent of Hashtable. You configure DynaCache to store objects, and later, based on some data matching rules, DynaCache retrieves those objects and serves them from its cache. Caching rules are stored in a configuration file called cachespec.xml. Single or multiple caches are supported. Caches are stored in the JVM heap memory and DynaCache supports overflow to disk if enabled and when required.
The system administrator has some degree of control over what is placed in memory and what (if anything) overflows to disk via configuration settings. DynaCache also calls a least recently used (LRU) algorithm during the item selection process for memory-based item eviction or overflow. The LRU algorithm consults with a user-specified cache entry priority number before the evictee is chosen. Higher numbered items stay in memory longer.
Disk offload of cache entries from memory occurs when the memory cache fills up or when the server is in the process of performing a normal, administrator-directed shut down and the "FlushToDiskOnStop" property is enabled. Upon a server restart, requests for cache entries are fulfilled by reloading the saved disk data into memory.
</snip>
<snip>
So friends, here in one of my assignment we are using dynacache to share object across application.
I posted my query on IBM developer works asking for how DynaCache works in cluster environment and i got one reply, so just thought of sharing on my blog.
DynaCache behaviour in clustered environment is somewhat different and need to take special attention.
Fist, if you don't have data replication domain setup in cluster environment each node has its own copy of the dynacache and which may cause issues in case of fail over or in case when objects are shared between diff application.
To use the your dynacache as global object across the cluster , you need create one data replication domain for the all nodes in the cluster and enable the data replication service.
To enable data replication service of dynacache, please refer to Configuring cache replication article in infocenter
</snip>
<snip>
Use this task to improve performance by configuring the data replication service (DRS) to replicate data from the dynamic cache service across the consumers in a replication domain.
</snip>
<snip>
With replication, data is generated one time and copied or replicated to other servers in the cluster, saving time and resources. Caching in a cluster has additional concerns. In particular, the same data can be required and generated in multiple places. Also, the permission the resources need to generate the cached data can be restricted, preventing access to the data.
Cache replication deals with these concerns by generating the data one time and copying it to the other servers in the cluster. It also aids in cache consistency. Cache entries that are not needed are removed or replaced.
Cache replication deals with these concerns by generating the data one time and copying it to the other servers in the cluster. It also aids in cache consistency. Cache entries that are not needed are removed or replaced.
</snip>
<snip>
Use this task to configure a data replication domain to transfer data, objects, or events for session manager, dynamic cache, or stateful session beans. Data replication domains use the data replication service (DRS), which is an internal product component that performs replication services, including replicating data, objects, and events among application servers.
</snip>
Configuring DynaCache
The dynamic cache service consolidates caching activities to improve application performance. By caching the response from servlets, web services, Java(TM) Server Pages (JSP) files, and WebSphere(R) Application Server commands, the application server does not have to perform the same computations and back-end queries multiple times.
Create the Replication Domain
Via the WAS Integrated Solutions Console (ISC), navigate to Environment > Replication domains )
Configure Dynacache
Via the WAS Integrated Solutions Console (ISC), navigate to Application servers > PCSR011.AppTarget ( your server name goes here ) > Dynamic cache service.
*UPDATE* I neglected to mention an excellent article on DynaCache, written by a former colleague of mine, Gab Telerman, that's also worth a read: -
Using DynaCache to improve the performance of your WebSphere Process Server or WebSphere ESB solution
In addition, Gab also recommended that I take a look at the jsCache toolkit on IBM Blueworks ....
No comments:
Post a Comment