On Aug 26, 2008, at 3:59 AM, Thorsten Scherler wrote:
On Mon, 2008-08-25 at 20:23 -0400, Vadim Gritsenko wrote:
On Aug 25, 2008, at 6:40 AM, Thorsten Scherler wrote:
...
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 :-)
Makes me wonder since HttpServletRequest is always unique as well
due to
the headers, so does not violate as well the whole locking?
HttpServletRequest is unique only in context of external request; but
it is same for multiple sub-requests of single external request.
Similarly, CommandLineRequest would be unique per single external
request, but shared across sub-requests.
At the same time, ObjectModelHelper.REQUEST_OBJECT will be always
unique: it will either be HttpServletRequest/CommandLineRequest for
top level, or Wrapper for nested requests.
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.
Understand but I am confused due to the above fact that the
HttpServletRequest is as well unique as it is my understanding.
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.
I now are using the url as lock key since as I understand it perfectly
qualifies as lock key.
Why not CommandLineRequest?
The patch is attached to COCOON-2241. As soon you are ok with it I
will
commit it.
I'd rather use CommandLineRequest; or at least change one line to be:
this.objectModel.put(CLI_REQUEST_ID, new String(uri));
Vadim
Thanks for your patience.
salu2
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
--
Thorsten Scherler
thorsten.at.apache.org
Open Source Java consulting, training and
solutions
