Caching strategy is one of the key design artifacts for any application, in terms of application performance, it is important to evaluate caching strategy at very early stages of application design, Caching can be applied at various layers of your application.
Caching strategy for an application starts from the client browser based caching, Edge side caching to server side grid caching.
In this article I'm going to talk about the server side caching options for WCS. eXtreme scale is IBM's next generation server side caching technology.
The dynamic cache engine is the default cache provider for the dynamic cache APIs and framework. However, starting with WAS Version 6.1.0.27, dynamic cache allows WebSphere eXtreme Scale Cache provider (Also, referred to as WXS),which is the strategic direction for caching for the WebSphere products, to act as its core caching engine.
In WCS 7 , this feature can be leveraged to make use of eXtreme Scale cache provider instead of the default dynamic cache engine, The default DynaCache provider is good enough for small applications and you have to do some due diligence before deciding to move to eXtreme Scale.
Refer to the decision tree flow chart in this article "Decision Tree for Migrating existing DynaCache Applications" to decide between default Dynacache and eXtreme Scale for your WCS implementation.
Let us first examine some of the issues with default Dyna Cache engine and what exactly does eXtreme Scale solve for us.
Design Flaws in Dyna Cache Engine
1. One of the major issues with DynaCache Engine in cluster mode is that it duplicates the cached objects across the clustered WCS instance. As depicted in the figure you can notice that the same object copy exists in all of the Dyna Cache instances, in case of eXtreme scale cache the Object copies are saved in an efficient manner by not duplicating across all of the cache memory, in case of WXS, the extreme scale engine knows on which JVM memory the Object cache resides and hence the object cache need not reside with the same JVM as the requesting client.
a. Increased space need to store the objects in default Dyna Cache Provider
b. Invalidation / updates of the objects requires additional overhead of synchronizing multiple copies of these objects across the clustered JVM's
eXtreme Scale Cache
1. WebSphere eXtreme Scale lets you leverage transactional support, improved scalability, high availability, and other WebSphere eXtreme Scale features without changing your existing dynamic cache caching code, I have underlined the previous line, it is important to note that the existing code is not impacted at all by changing the cache provider, the cache provider in this case works like plug and play.
If you are currently using the default cache provider, you can use the administrative console or wsadmin commands to replace the default dynamic cache provider with the WebSphere eXtreme Scale dynamic cache provider. You do not have to make any changes to your dynamic cache programming model.
2. Refer to following article for more details around How to configure dynamic cache provider for websphere eXtreme Scale.
3. One of the key differences from default DyanCache provider is that the cached data is stored in WebSphere eXtreme Scale containers. These containers can run inside or outside of a WebSphere Application Server process (In case of default DynaCache provider you are making use of WCS JVM space to store the cached data).
The eXtreme Scale provider automatically creates containers inside a WebSphere Application Server process when you are using embedded or embedded partitioned topologies for a cache instance (This configuration is good enough for small projects). No further configuration is needed for these topologies.
When you are using the remote topology (This configuration is preferred for large projects which may have huge amount of data in server side cache), you must start up stand-alone eXtreme Scale containers before you start the WebSphere Application Server instances that access the cache instance.
eXtreme Scale is a comprehensive topic, I have definitely not captured all of the benefits of eXtreme Scale, Refer to some of the links provided in this blog for detailed undertanding of eXtreme Scale.
Replacing DynaCache with WebSphere extreme Scale
WebSphere eXtreme Scale WIKI
Caching strategy for an application starts from the client browser based caching, Edge side caching to server side grid caching.
In this article I'm going to talk about the server side caching options for WCS. eXtreme scale is IBM's next generation server side caching technology.
The dynamic cache engine is the default cache provider for the dynamic cache APIs and framework. However, starting with WAS Version 6.1.0.27, dynamic cache allows WebSphere eXtreme Scale Cache provider (Also, referred to as WXS),which is the strategic direction for caching for the WebSphere products, to act as its core caching engine.
In WCS 7 , this feature can be leveraged to make use of eXtreme Scale cache provider instead of the default dynamic cache engine, The default DynaCache provider is good enough for small applications and you have to do some due diligence before deciding to move to eXtreme Scale.
Refer to the decision tree flow chart in this article "Decision Tree for Migrating existing DynaCache Applications" to decide between default Dynacache and eXtreme Scale for your WCS implementation.
Let us first examine some of the issues with default Dyna Cache engine and what exactly does eXtreme Scale solve for us.
Design Flaws in Dyna Cache Engine
1. One of the major issues with DynaCache Engine in cluster mode is that it duplicates the cached objects across the clustered WCS instance. As depicted in the figure you can notice that the same object copy exists in all of the Dyna Cache instances, in case of eXtreme scale cache the Object copies are saved in an efficient manner by not duplicating across all of the cache memory, in case of WXS, the extreme scale engine knows on which JVM memory the Object cache resides and hence the object cache need not reside with the same JVM as the requesting client.
a. Increased space need to store the objects in default Dyna Cache Provider
b. Invalidation / updates of the objects requires additional overhead of synchronizing multiple copies of these objects across the clustered JVM's
eXtreme Scale Cache
1. WebSphere eXtreme Scale lets you leverage transactional support, improved scalability, high availability, and other WebSphere eXtreme Scale features without changing your existing dynamic cache caching code, I have underlined the previous line, it is important to note that the existing code is not impacted at all by changing the cache provider, the cache provider in this case works like plug and play.
If you are currently using the default cache provider, you can use the administrative console or wsadmin commands to replace the default dynamic cache provider with the WebSphere eXtreme Scale dynamic cache provider. You do not have to make any changes to your dynamic cache programming model.
2. Refer to following article for more details around How to configure dynamic cache provider for websphere eXtreme Scale.
3. One of the key differences from default DyanCache provider is that the cached data is stored in WebSphere eXtreme Scale containers. These containers can run inside or outside of a WebSphere Application Server process (In case of default DynaCache provider you are making use of WCS JVM space to store the cached data).
The eXtreme Scale provider automatically creates containers inside a WebSphere Application Server process when you are using embedded or embedded partitioned topologies for a cache instance (This configuration is good enough for small projects). No further configuration is needed for these topologies.
When you are using the remote topology (This configuration is preferred for large projects which may have huge amount of data in server side cache), you must start up stand-alone eXtreme Scale containers before you start the WebSphere Application Server instances that access the cache instance.
eXtreme Scale is a comprehensive topic, I have definitely not captured all of the benefits of eXtreme Scale, Refer to some of the links provided in this blog for detailed undertanding of eXtreme Scale.
Replacing DynaCache with WebSphere extreme Scale
WebSphere eXtreme Scale WIKI
Hari, thanks for writing this blog. I have been exposed with WC since last July, but I am still finding myself struggling with it. Although the infocenter is really helpful, I wish I could found more "for dummies" resource related to WC. It is really good to find this blog (and I quickly subscribe to your blog via Google Reader). Keep writing!
ReplyDeletegood to hear that, you should be having your new google wave account in your inbox.
ReplyDeleteHari,
ReplyDeleteThanks for this info. I would like to know how to invalidate the cache when e-marketing spot is changed. Usually we add the e-marketing spot to be cached but i didnt see any way in which i can invalidate the cache when i change content of e-spot dynamically. Please advise.
Thanks
naveen.
email id: naveen.kumars@target.com