WSO2 Business Process Server v3.1.0 Documentation

##### Overview

- Home
- Release Note
- WS-BPEL Compliance
- License

##### Downloads

- Releases

##### Installation Guide

- Installing WSO2 BPS

##### Quick Start Guide

- Modeling the process
- Deploying the process
- Testing the process

##### User Guide

- Deploying BPEL Processes
- Deploying Human Tasks
- Managing BPEL processes
- Managing BPEL process instances
- QoS for BPEL processes
- Securing BPEL processes
- Invoking secured partner services
- Versioning
- Management API

##### Human Task Guide

- Human Tasks Quick Start Guide
- Deploying HumanTasks
- Managing Tasks
- Developing a Human Task Artifact
- Human Task Management and Configuration
- Human Task Concepts

##### Administrator Guide

- External data sources Configuration
- Registry Configuration
- Events
- Unified Endpoints
- BPEL Extensions
- Transaction Factory Configuration
- Message Exchange Interceptors
- OpenJPA specific properties
- JMS Transport Configuration
- Process Instance Cleanup Tasks
- Process Hydration and Dehydration
- Enabling Peer-to-Peer(P2P) Communication
- Setting up a BPS Cluster

##### Best Practices

- Process Deployment Best Practices

##### Concepts

- Process Versioning
- Process instance events
- Partner links

##### WS-BPEL Extensions

- Activity Failure and Recovery
- Extension Activities and Extensible Assign Operations
- XPath Extensions
- Iterable ForEach
- Flexible Assigns
- BPEL4People Extension

##### Samples

- HelloWorld
- If-Else
- ForEach
- While
- Repeat Until
- Flow and Links
- Pick
- Synchronous and Asynchronous Service Invocations
- Fault Handling
- Split
- XslTransform
- Compensation Handler
- Event Handler

##### Resources

- FAQ
- External Articles
- Library
- Source Code

##### Community

- Forum
- Mailing Lists

##### Project Information

- Issue Tracking

# Response Caching

WSO2 Carbon provides a caching tool that is used to cache responses for requests that are identical, thereby enhancing the response time for subsequent requests. When caching is enabled, subsequent requests with same hash value as the previous request whose response was cached, will be served with the same cached response. Caching can be enabled at three levels.

1. Service level: If caching is engaged at service level, all the responses that are generated by all the operations of that particular service will be cached.
2. Global level: Global level engagement of caching will apply caching for all the messages coming into a hosted server instance. All the responses from all the services will be cached.
3. Operation level: If engaged at operation level, only those responses from that particular operation of a given service will be cached.

## Adding Response Caching to the Service

Adding response caching reduces the overhead of XML processing or object copying. It helps clients to participate transparently in the existing Web services community.

The caching option is disabled by default, therefore it must be enabled.

1. In the navigator, under Manage/Service, click List. The Deployed Services page appears.
2. Click the service for which you want to add caching. The Service Dashboard page appears.
3. In the Quality of Service Configuration panel, click Response Caching. The Caching Configuration page appears.
4. In the Enable Caching list, click Yes. The last saved configuration or the default configuration (if it is the first time) for caching will be displayed.
5. Modify the configuration as required, and click Finish . Caching will be engaged for that particular service globally.

Figure 1: Configuration for Response Caching

Field Description

### Fields in Wizard

Field Name | Description
Hash Generator | This specifies the fully qualified class name of the hash value generator. This class implements the org.wso2.caching.digest.DigestGenerator interface. It is responsible for generating a Hash value for each request message, so that a matching response message can be located from the cache. The default is org.wso2.caching.digest.DOMHASHGenerator. You can implement your own Hash generator class and use it with the WSO2 Carbon based product. However, the default hash generator should be good enough for general use.
Timeout | This is the time period, in milliseconds, that a cached response is kept in memory. The counting starts from the time the first request is received. Any request received after the counter has started and is within the Timeout period, is served with the response cached upon receiving the first request. Once the Timeout expires, the cache will be updated with the response generated for the first request that was received after the expiry.
Maximum Cache Size | This holds the maximum number of response messages that will be cached. If the maximum number of responses are already cached and none of the cached responses' Timeouts have expired, then future responses are not cached until this memory is free enough to accommodate caching a new response.
Maximum Message Size | The response message that is cached. Response messages larger than this (in size) are not cached. Caching is an expensive operation for larger messages, especially given the amount of memory required. Therefore this value should be set considering the performance and resource trade-offs.

Note:

- It is advised that you consider the dynamic nature of your services before you enable caching globally. For example, an operation that is supposed to generate random numbers would not benefit from caching previous responses, because it is supposed to generate a unique response for each invocation.
- WSO2 Carbon based products support configuring caching at service level and global level. If you want to engage the caching capability at operational level, you have to edit the configuration file of the service manually and engage it at operation level.