DynaCache provides support for caching the returned results from Java™ object calls. DynaCache provides a very straightforward mechanism that allows you to cache the results from these Java command objects; it is called command caching.
Commands written to the WebSphere® command architecture access databases, file systems, and connectors to perform business logic, and often run remotely on another server. Significant performance gains can be achieved by caching command results and avoiding their repeated invocation.
To take advantage of command caching, applications must be written to the WebSphere command framework API. This API is based on a common programming model, and uses a series of getters(), setters() and execute() methods to retrieve its results. To use a command, the client creates an instance of the command and calls the execute() method for the command. Depending on the command, calling other methods could be necessary. The specifics will vary with the application.
With Command cache, the data is cached before it is transformed into HTML. In order to take advantage of command caching, you must make simple code changes to your Java objects so that DynaCache can call them to retrieve the data. Command objects inherit from com.ibm.websphere.command.cachableCommandImpl and must provide certain methods to function properly.
Executed command objects can be stored in the cache so that subsequent instances of that command object's execute method can be served by copying output properties of the cached command to the current command for retrieval by its get methods. DynaCache supports caching of command objects for later reuse by servlets, JSPs, EJBs, or other business logic programming.
Interface (Example):
public interface CustomerRepsRetrieveCmd extends TargetableCommand{
// set default command implement class
static final String defaultCommandClassName = "com.abccompany.commerce.commands.CustomerRepsRetrieveCmdImpl";
/* property getters and setters go here */
public String getCustomerId();
public void setCustomerId(String customerId);
public List getCustomerRepsList();
}
Implementation Class (Example):
public class CustomerRepsRetrieveCmdImpl extends CacheableCommandImpl implements CustomerRepsRetrieveCmd { private String customerId; private List customerRepsList; // called to validate that command input parameters have been set public boolean isReadyToCallExecute() { return (getCustomerId() != null && !"".equals(getCustomerId())); } // called by a cache-hit to copy output properties to this object public void setOutputProperties(TargetableCommand cmd) { CustomerRepsRetrieveCmd repsRetrieveCmd = (CustomerRepsRetrieveCmd) cmd; setCUstomerRepsList(repsRetrieveCmd.getCustomerRepsList()); }
public void performExecute() throws Exception {
/* business logic code goes here */
ABCSession abcSession = Utilities.getABCSession();
if(getCustomerId() != null && !"".equals(getCustomerId())) {
setCustomerRepsList(abcSession.getCustomerReps(getCustomerId()));
} else {
setCustomerRepsList(new ArrayList());
}
}
/* property getters and setters go here */
public List getCustomerRepsList() {
return customerRepsList;
}
protected void setCustomerRepsList(List repsList) {
this.customerRepsList = repsList;
}
public String getCustomerId() {
return customerId;
}
public void setCustomerId(String customerId) {
this.customerId = customerId;
}
}
Cacheable objects are also defined in the cachespec.xml file found inside the Web application archive (WAR) , Web module WEB-INF directory, or enterprise bean WEB-INF directory. A global cachespec.xml file can also be placed in the application server properties directory, but the recommended method is to place the cache configuration file with the deployment module.
Info pulled from the IBM documentation:
Command cache
CacheableCommandImpl
CacheableCommand
Configuring the dynamic cache service in cachespec.xml
