On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
On Fri, 2008-08-22 at 10:34 -0400, Vadim Gritsenko wrote:
On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:
So which object you would suggest to lock?
You wrote "Suitable alternative would be to lock against top most
command line request."
To what you are referring with "top most command line request"?
That would be CommandLineRequest.
Hmm, did you see the above objectModel? There is no such an object in
the map. There are exactly six objects in the model
1) response
2) link-collection
3) request
4) context
5) source-resolver
6) org.apache.cocoon.components.CocoonComponentManager
Yes, it currently does not exist.
Following HTTP environment analogy,
that would be CommandLineEnvironment.CLI_REQUEST_OBJECT.
Which does not exist, right?
Correct. At the moment, it does not exist.
I opened an issue COCOON-2241 around the issue.
The proposed solution is now taken the
ObjectModelHelper.REQUEST_OBJECT
if the request is from CLI, if not it is using the
HttpEnvironment.HTTP_REQUEST_OBJECT.
IMO it should not be a problem with deadlocks since the
FileSavingEnvironment and LinkSamplingEnvironment (as only
implementations for the Cli) have in the constructor:
this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT,
new CommandLineRequest(this, null, uri, null, attributes, parameters,
headers));
which IMO makes it unique for each sub-request.
Yes, ObjectModelHelper.REQUEST_OBJECT object is always unique. It is
actually unique in any environment. And since it is unique, it does
not make sense to lock on it at all - lock on unique object serves no
purpose :-)
You could, for example, have same effect with code:
// Avoids NPE, does nothing
if (lock == null) lock = new Object();
To get back to the problem... The original goal of pipeline locking
was to prevent separate external requests to start generating cached
response for the same resource-intensive resource. In other words, if
too external requests both (directly or through aggregation) hit '/
slow/cached/foo' resource, only one request will trigger this
pipeline, while another will wait for the first to complete.
This logic, in turn, had to be augmented to exclude single external
request hitting the same slow resource twice due to aggregation (and
parallel aggregation), hence locking against top level external
request was implemented.
Now, in situation when CommandLineEnvironment is used from the, ahem,
command line, two external requests will not happen. Which means that
whole pipeline locking thing is irrelevant and can be omitted
completely (like in 'lock = new Object()' snippet above). But, the
same CommandLineEnvironment stuff can be used in multi threaded
environment which uses the CocoonBean class. So, strictly speaking, in
this scenario locking still should be performed against external
request object, and not against any RequestWrapper which is unique for
each sub-request.
Hope now it all makes more sense.
Regards,
Vadim
In comparison the HttpEnvironment has in the constructor:
this.objectModel.put(HTTP_REQUEST_OBJECT, req);
where HttpServletRequest req.
The uniqueness in both cases are, as I understand, the headers.
salu2
