[Seaside] state in request handler

[Norbert Hartl]

Am 17.04.2012 um 15:34 schrieb Julian Fitzell:

> On Fri, Apr 13, 2012 at 10:37 AM, Lukas Renggli <renggli at gmail.com> wrote:
>> On 13 April 2012 10:26, Norbert Hartl <norbert at hartl.name> wrote:
>>> 
>>> Am 13.04.2012 um 08:13 schrieb Milan Mimica:
>>> 
>>> On 12 April 2012 23:46, Norbert Hartl <norbert at hartl.name> 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.
> 
That is what I meant with request context being adaptive ;) I think hooking onto request context is good if you don't care to have WACurrentRequestContext calls in your code. In my case I liked to make it request independent and the suggestion of Lukas is the perfect match. The request context hook-on could be in favour if thread-safety has hard requirements. But that is just an assumption because I do not know the constraints when a context is allowed to be suspended.

Norbert