[Seaside] state in request handler

Norbert Hartl norbert at hartl.name
Fri Apr 13 08:26:10 UTC 2012

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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20120413/914ea5e5/attachment.htm

More information about the seaside mailing list