I've just faced an issue with the Cocoon caching related to POST requests. Let me describe the use case here. We use a custom XQueryGenerator to execute XQuery code over Sedna XML Database and then process the XML results in the Cocoon pipeline. For the sake of performance, I configured the pipeline caching based on the expiration timeout of 60 seconds for all XQuery invocations:
<map:pipeline id="cached-services" type="expires" internal-only="true"> <map:parameter name="cache-expires" value="60"/> <map:parameter name="cache-key" value="{request:sitemapURI}?{request:queryString}"/> <map:match pattern="cached-internal-xquery/**"> <map:generate src="cocoon:/xquery-macro/{1}" type="queryStringXquery"> <map:parameter name="contextPath" value="{request:contextPath}"/> </map:generate> <map:transform src="xslt/postprocessXqueryResults.xslt" type="saxon"/> <map:serialize type="xml"/> </map:match> </map:pipeline>
So you can see that both a request sitemap URI and a query string are used to form the cache key. It works perfectly until you want to send XQuery parameters via POST method instead of GET. Then the query string will be empty and identical for all the POST requests. As a result, one POST request's results will be cached for all of them, the caching breaks it all.
You may wonder why we need POST requests to actually load XML data. This is because we cannot predict how many request parameters will be there as they are generated from the list of identifiers like this:
You may wonder why we need POST requests to actually load XML data. This is because we cannot predict how many request parameters will be there as they are generated from the list of identifiers like this:
// id_list is a Collection of identifiers to be sent as request parameters var postData = id_list.stringJoin( function(object) { return "id=" + object }, "&" ); var uri = "xquery/basictype_tree"; // This sends an asynchronous request and // inserts its results into the containerId element. new SimpleContainerTransaction( { "uri": uri, "containerId": "treenode-details-container", "method": "POST", "data": postData } ).execute();
Here the SimpleContainerTransaction is a part of a custom YUI3-based Transaction utility.
Now it's time to fix the issue. It seems quite obvious that we should simply generate a fake GET parameter in addition to meaningful POST parameters. This fake parameter will be a hash of POST parameters to make identical requests have identical hash values. As soon as we implement this, the caching should work perfectly for this use case as well.
As we generate POST parameters string in JavaScript, I googled for JavaScript hash implementations and discovered this pretty overview of possible JavaScript hash solutions. So I adapted the first one and incorporated it into our project JS library:
Now it's time to fix the issue. It seems quite obvious that we should simply generate a fake GET parameter in addition to meaningful POST parameters. This fake parameter will be a hash of POST parameters to make identical requests have identical hash values. As soon as we implement this, the caching should work perfectly for this use case as well.
As we generate POST parameters string in JavaScript, I googled for JavaScript hash implementations and discovered this pretty overview of possible JavaScript hash solutions. So I adapted the first one and incorporated it into our project JS library:
String.prototype.hashCode = function() { var charCode, hash = 0; if (this.length == 0) return hash; for (var i = 0; i < this.length; i++) { charCode = this.charCodeAt(i); hash = ((hash << 5) - hash) + charCode; hash = hash & hash; // Convert to 32bit integer } return hash; }
This extends all String objects' with the hashCode function. So let's fix now the caching issue by appending POST parameters hash as a GET parameter to the URL:
var uri = "xquery/basictype_tree?hash=" + postData.hashCode();
That's it, the caching works fine again.
Comments
Post a Comment