cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [2.1] AbstractCachingProcessingPipeline and cocoon CLI
Date Fri, 22 Aug 2008 14:34:49 GMT
On Aug 22, 2008, at 8:57 AM, Thorsten Scherler wrote:

> On Fri, 2008-08-22 at 08:18 -0400, Vadim Gritsenko wrote:
>> On Aug 22, 2008, at 3:35 AM, Thorsten Scherler wrote:
>>
>>> How about:
>>>                } else {
>>> -                    Object lock =
>>> env.getObjectModel().get(HttpEnvironment.HTTP_REQUEST_OBJECT);
>>> +                    Object lock =
>>> env.getObjectModel().get(ObjectModelHelper.REQUEST_OBJECT);
>>>                    try {
>>>                        transientStore.store(lockKey, lock);
>>>                    } catch (IOException e) {
>>>
>>> This way we always lock the same object.
>>
>> Exactly this thing I was trying to explain - it will not work because
>> instead of using top level request you are suggesting to use current
>> sub-request.
>
> Sorry I am not really following. As understand you we cannot use
> ObjectModelHelper.REQUEST_OBJECT since we cannot be sure that is not a
> sub-request (a request for the exact same resource in a concurrent
> situation).

Exactly.


> If the lock is null for a HttpEnvironment.HTTP_REQUEST_OBJECT then we
> are in CLI mode.

(patch quoted above does not have lock == null comparison anymore,  
that's why it is dangerous for HTTP env)


> In CLI ASAIK there is no concurrent situation meaning
> the problem cannot occur. However since the issue is talking about
> includes that may occur.

Yes. You can still use IncludeTransformer in CLI. So deadlock can  
happen.


> Having a typical call from the cli gives for the env.getObjectModel():
>
> HashMap values:
> [null,
> response=org.apache.cocoon.environment.wrapper.ResponseWrapper@fd4662,
> link-collection=[],
> request=org.apache.cocoon.environment.wrapper.RequestWrapper@6dddcf,
> null, null, null, null,
> context 
> = 
> org 
> .apache.cocoon.environment.commandline.CommandLineContext@14ba9a2,  
> null, null, source- 
> resolver 
> = 
> org 
> .apache.cocoon.environment.commandline.FileSavingEnvironment@725967,  
> org 
> .apache 
> .cocoon 
> .components 
> .CocoonComponentManager 
> =org.apache.cocoon.components.EnvironmentDescription@d2efa1, null,  
> null, null]
>
> 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. Following HTTP environment analogy,  
that would be CommandLineEnvironment.CLI_REQUEST_OBJECT.


Vadim


> salu2
>
>>
>> Take a look at EnvironmentWrapper (which is used e.g. in  
>> SitemapSource):
>>
>>         // create new object model and replace the request object
>>         Map oldObjectModel = env.getObjectModel();
>>         if (oldObjectModel instanceof HashMap) {
>>             this.objectModel = (Map) 
>> ((HashMap)oldObjectModel).clone();
>>         } else {
>>             this.objectModel = new HashMap(oldObjectModel.size()*2);
>>             Iterator entries = oldObjectModel.entrySet().iterator();
>>             Map.Entry entry;
>>             while (entries.hasNext()) {
>>                 entry = (Map.Entry)entries.next();
>>                 this.objectModel.put(entry.getKey(),  
>> entry.getValue());
>>             }
>>         }
>>         this.request = new
>> RequestWrapper(ObjectModelHelper.getRequest(oldObjectModel),
>>                                           requestURI,
>>                                           queryString,
>>                                           this,
>>                                           rawMode);
>>         this.objectModel.put(ObjectModelHelper.REQUEST_OBJECT,
>> this.request);
>>
>>
>> Vadim
> -- 
> Thorsten Scherler                                  
> thorsten.at.apache.org
> Open Source Java                      consulting, training and  
> solutions
>


Mime
View raw message