RE: Blocking of simultaneous requests

["Marcelo F. Ochoa" <mo...@ieee.org>]

The intention of the block inner class was simple. If caching is to work on
particularly cumbersome documents (for instance ones that require massive
XSLT transformations) without bringing the JVM to a grinding halt under
conditions of high concurrency, the block class ensures that the document is
in cache. 
How about the well knowed method isCacheable for the producers?
This method means "the content of this producer is never cacheable", for example DB Prism producer.
In this kind of producer the cache behaviour is implemented outside the Cocoon and the functionality of this producer is only route the request, then there aren't concurrency problem.

Of course this is predicated on the idea that documents are coming of disk.
It's tricky. The concurrency issue shouldn't be dealt with in the Engine
class, but we had no choice when working with the document bases we were
working with. 

We'd like to move the concurrency handling to another layer, just haven't
had time . . . 
Best regards, Marcelo.