state in request handler

>
> Am 13.04.2012 um 08:13 schrieb Milan Mimica:
>
> On 12 April 2012 23:46, Norbert Hartl <[hidden email]> wrote:
>>
>> I'm using a seaside rest handler and I was wondering today how concurrency
>> issues are handeld there. The request handler is a component that is always
>> the same object for incoming requests. I need to set  a heavy weight
>> component at incoming request and I want to have it accessible until the
>> response is send. Where is the be place to put such kind of state?
>> Starting to add an instance variable in the request handler I had the
>> impression this is a bad thing to do. And then I was wondering how multiple
>> threads are handled in seaside. Or better what operation can be considered
>> thread safe and where I need to put extra effort to protect intermediate
>> state while processing. My component needs to be initialized by the incoming
>> request context and is accessed multiple times until process has finished.
>
>
> You could make it thread-local. Look at how WACurrentRequestContext is
> implemented.
>
> I see. Although I think thread-locality here is a coincidence. And
> WARequestContext is adaptive so I could hook my stuff onto it. I need to
> make my component aware of the request context. I'm not convinced this is
> the best way to go but it would work I think.
> Probably that solves my other problem, too. With having a state within the
> request handler there needs to be a location where this state is to be
> resetted. I thought handleFiltered: would be called only once. But this is
> not true at least not when running it inside a test case. Or I need to try
> to investigate further.

> On 13 April 2012 10:26, Norbert Hartl <[hidden email]> wrote:
>>
>> Am 13.04.2012 um 08:13 schrieb Milan Mimica:
>>
>> On 12 April 2012 23:46, Norbert Hartl <[hidden email]> wrote:
>>>
>>> I'm using a seaside rest handler and I was wondering today how concurrency
>>> issues are handeld there. The request handler is a component that is always
>>> the same object for incoming requests. I need to set  a heavy weight
>>> component at incoming request and I want to have it accessible until the
>>> response is send. Where is the be place to put such kind of state?
>>> Starting to add an instance variable in the request handler I had the
>>> impression this is a bad thing to do. And then I was wondering how multiple
>>> threads are handled in seaside. Or better what operation can be considered
>>> thread safe and where I need to put extra effort to protect intermediate
>>> state while processing. My component needs to be initialized by the incoming
>>> request context and is accessed multiple times until process has finished.
>>
>>
>> You could make it thread-local. Look at how WACurrentRequestContext is
>> implemented.
>>
>> I see. Although I think thread-locality here is a coincidence. And
>> WARequestContext is adaptive so I could hook my stuff onto it. I need to
>> make my component aware of the request context. I'm not convinced this is
>> the best way to go but it would work I think.
>> Probably that solves my other problem, too. With having a state within the
>> request handler there needs to be a location where this state is to be
>> resetted. I thought handleFiltered: would be called only once. But this is
>> not true at least not when running it inside a test case. Or I need to try
>> to investigate further.
>
> I would just create a new object for each incoming request in the
> Seaside request handler. Like this you can safely keep your state
> separate from all other incoming requests and it gets garbage
> collected as soon as the request completes.
>
> SeasideRequestHandler>>#handleRequest: aRequestContext
>     ^ MyRequestHandler new handle: aRequestContext
>

> On 13 April 2012 10:26, Norbert Hartl <[hidden email]> wrote:
>>
>> Am 13.04.2012 um 08:13 schrieb Milan Mimica:
>>
>> On 12 April 2012 23:46, Norbert Hartl <[hidden email]> wrote:
>>>
>>> I'm using a seaside rest handler and I was wondering today how concurrency
>>> issues are handeld there. The request handler is a component that is always
>>> the same object for incoming requests. I need to set  a heavy weight
>>> component at incoming request and I want to have it accessible until the
>>> response is send. Where is the be place to put such kind of state?
>>> Starting to add an instance variable in the request handler I had the
>>> impression this is a bad thing to do. And then I was wondering how multiple
>>> threads are handled in seaside. Or better what operation can be considered
>>> thread safe and where I need to put extra effort to protect intermediate
>>> state while processing. My component needs to be initialized by the incoming
>>> request context and is accessed multiple times until process has finished.
>>
>>
>> You could make it thread-local. Look at how WACurrentRequestContext is
>> implemented.
>>
>> I see. Although I think thread-locality here is a coincidence. And
>> WARequestContext is adaptive so I could hook my stuff onto it. I need to
>> make my component aware of the request context. I'm not convinced this is
>> the best way to go but it would work I think.
>> Probably that solves my other problem, too. With having a state within the
>> request handler there needs to be a location where this state is to be
>> resetted. I thought handleFiltered: would be called only once. But this is
>> not true at least not when running it inside a test case. Or I need to try
>> to investigate further.
>
> I would just create a new object for each incoming request in the
> Seaside request handler. Like this you can safely keep your state
> separate from all other incoming requests and it gets garbage
> collected as soon as the request completes.
>
> SeasideRequestHandler>>#handleRequest: aRequestContext
>     ^ MyRequestHandler new handle: aRequestContext
>

> On Fri, Apr 13, 2012 at 10:37 AM, Lukas Renggli <[hidden email]> wrote:
>> On 13 April 2012 10:26, Norbert Hartl <[hidden email]> wrote:
>>>
>>> Am 13.04.2012 um 08:13 schrieb Milan Mimica:
>>>
>>> On 12 April 2012 23:46, Norbert Hartl <[hidden email]> wrote:
>>>>
>>>> I'm using a seaside rest handler and I was wondering today how concurrency
>>>> issues are handeld there. The request handler is a component that is always
>>>> the same object for incoming requests. I need to set  a heavy weight
>>>> component at incoming request and I want to have it accessible until the
>>>> response is send. Where is the be place to put such kind of state?
>>>> Starting to add an instance variable in the request handler I had the
>>>> impression this is a bad thing to do. And then I was wondering how multiple
>>>> threads are handled in seaside. Or better what operation can be considered
>>>> thread safe and where I need to put extra effort to protect intermediate
>>>> state while processing. My component needs to be initialized by the incoming
>>>> request context and is accessed multiple times until process has finished.
>>>
>>>
>>> You could make it thread-local. Look at how WACurrentRequestContext is
>>> implemented.
>>>
>>> I see. Although I think thread-locality here is a coincidence. And
>>> WARequestContext is adaptive so I could hook my stuff onto it. I need to
>>> make my component aware of the request context. I'm not convinced this is
>>> the best way to go but it would work I think.
>>> Probably that solves my other problem, too. With having a state within the
>>> request handler there needs to be a location where this state is to be
>>> resetted. I thought handleFiltered: would be called only once. But this is
>>> not true at least not when running it inside a test case. Or I need to try
>>> to investigate further.
>>
>> I would just create a new object for each incoming request in the
>> Seaside request handler. Like this you can safely keep your state
>> separate from all other incoming requests and it gets garbage
>> collected as soon as the request completes.
>>
>> SeasideRequestHandler>>#handleRequest: aRequestContext
>>     ^ MyRequestHandler new handle: aRequestContext
>>
>
> Or, you could store your data in the request context (it has a
> property dictionary). However, I think I prefer Lukas' suggestion if
> it makes sense for your case.
>