[Dancer-users] messed up routes

[Richard Huxton]

On 20/10/11 21:57, Puneet Kishor wrote:
>
> On Oct 20, 2011, at 2:50 PM, Richard Huxton wrote:
>> Sorry - we're using different terminology. Starman has a --workers option which you usually set to something greater than 1. Each one will have its own settings (including the "layout" setting). Each request can go to a different worker. So you can end up with:
>> request 1: login page - worker 1 - sets layout = nomenu
>> request 2: home page  - worker 2 - sets layout = menu
>> request 3: news page  - worker 1 - will start with layout=nomenu
>>
>> Now, if request 3 had gone to worker 2 you would have had a
>> default
>> layout of "menu" instead. I think this is what you are seeing, you can
>> see how if you've got 10 workers the situation can get confusing.

> This is brilliant information. I never made this connection. Thanks a
> ton for this as this will allow me to be more careful with the way I
> code my apps. I guess the main thing is to be as specific as possible
> vis a vis routes and templates.

Whenever you have more than one context for your data, or more than one 
worker operating on it you need to be careful with this sort of thing.

There are two different axes you need to think about it:
lexical scope
- per function
- per module
- per backend
- global (e.g. session storage, databases)
temporal scope
- per request (dancer params)
- per session (dancer sessions)
- per backend lifetime (our $var)
- long-term (databases)

If some value (like layout) isn't in the grid you think it is, you get 
unexpected behaviour. Likewise putting information in the wrong grid 
(e.g. "current client" isn't session-based) can cause problems.

You'll get similar unexpected behaviour when you have concurrency issues 
with multiple workers operating on shared data. What works fine with a 
single worker can intermittently fail with multiple ones.

-- 
   Richard Huxton
   Archonet Ltd