In this V9 Chats series, we go to the source and interview Commerce experts from the Development, Services and Support teams, who share their insight into the new features and capabilities of WebSphere Commerce V9.
Caching and Invalidation
Q: V9 brings some important technology changes. How do this impact the caching strategy compared to older releases?
Shoeb: For the most part, caching remains the same. We still rely on the CACHEIVL table and DynaCache on the WebSphere Commerce JVMs, and this is supported with Edge and CDN caching. Still, with the introduction of the store (CRS) and the customization(Xc) servers, and the new use of Liberty server in Docker, we had to make changes to how invalidations are handled.
Q: The Store and Customization servers run on Liberty, which doesn't support DRS. How is that handled?
Joe: You're right--these servers run with Liberty, which doesn't support DRS. For V9, we had to implement an alternative for propagating invalidations. We chose Kafka, which is one of the most popular message streaming systems. In fact, DRS is not there for the transaction server as well--this is due to the absence of the WAS cluster. Both DRS and WAS clustering was sacrificed to get better out of docker technology. We recommended Kafka as the messaging System mostly because it's popular, and easy to understand and setup. Also, it's open source. Not to mention the low hardware cost and high throughput it can achieve.
Q: Is Kafka part of Commerce now?
Shoeb: No, Kafka is not included with the Commerce images. It is an open source project that can be installed separately on a VM, bare metal, or it can be containerized. Various docker images for Kafka are available on docker hub. Under reading material, I will include a blog article on how to setup Kafka using docker image and manage it using Zookeeper.
Q: Do all the servers use Kafka?
Shoeb: No, currently Kafka/Zookeeper messaging system for invalidation is only used by the Transaction and Store server. Search server continues to work the same as in earlier versions, where it would query CACHEIVL table for invalidations. Whereas, xC server is open to customization and it strictly depends on clients requirement/preference.
Q: Does IBM provide any reference material to configure and invalidate cache on xC Server?
Joe: Yes--IBM has provided sample logic for xC server. The customer has the freedom to add or change this provided sample logic. If necessary, new sets of data caches can be added from performance standpoints, and since we have exposed the Kafka structure, the customer can directly monitor the existing invalidation topics for invalidation. In addition, IBM has provided how information on how messages are composed, and how invalidation topics are named. A customer can also use any software stack as the implementation for xC programming model (Node.js, Python, PHP), and Kafka has client libraries to support a wide range of technology.
Q: If I store all caches in WXS, do I still need Kafka?
Joe: WXS hasn't been fully adopted. There is still some work left to enable it for the docker world. Even with WXS, we recommend you setup Kafka messaging system for frequent cache invalidations, such as user/session data.
The authors shared the following links to continue learning about the topic: