Home | Previous | Next
WAS dynamic cache vs. WXS data grid
- No change to application
The application continues to use the dynamic cache provider and does not need to be changed.
- Remote cache
With the remote topology, all cache access is remote. There is currently no in-memory cache, or "near cache" for the dynamic cache plug-in. As a result, there will be a heavier requirement of network bandwidth to the cache than previously.
For more advanced topologies, it is possible to host a number of grids in eXtreme Scale. These can be for other integration scenarios such as the Portal integration scenario, applications with custom coding, or even multiple dynamic cache grids.
- eXtreme Scale is partitioned
Because the eXtreme Scale grid is partitioned to allow it to scale, there are factors in...
- Distributed cache instead of cache replication
The default dynamic cache provider is a replicated cache instead of a distributed cache. Therefore certain of the modes that the dynamic cache provider allowed were to address performance impacts of replicating lots of data around an environment. Often environments needed to be configured to just replicate cache invalidations, or just replicate data when it is needed by another server (cache replication modes "not shared", "pull/push" respectively).
By contrast, eXtreme Scale in a remote topology only has a single primary copy of the data, which the applications all have access to. So there will not be the scenario where more than one server has to create the cache entry with the potential issues that introduces. The impact of this is just a different (and often simpler) approach to configuring caching.
- Cache availability
Instead of replicating an entire cache throughout a Commerce environment, eXtreme Scale can be configured to maintain a copy of each partition on a separate server. It is configurable as to whether this is synchronous or asynchronous and how many copies (replicas) are needed. One asynchronous replica will give sufficient availability in most situations.