On Thu, 2008-08-28 at 07:44 -0400, Vadim Gritsenko wrote:
> 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?
Hmm, because it would be the same as ObjectModelHelper.REQUEST_OBJECT
this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT, new
CommandLineRequest(this, null, uri, null, attributes, parameters,
headers));
However if you recommend to do:
CommandLineRequest request = new CommandLineRequest(this, null, uri,
null, attributes, parameters, headers);
this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT,
request);
this.objectModel.put(CLI_REQUEST, request);
That is as well fine with me.
wdyt?
Thanks for your feedback.
salu2
>
>
> > 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
> >
>
--
Thorsten Scherler thorsten.at.apache.org
Open Source Java consulting, training and solutions
