[Seaside] Concurrent requests from multiple sessions

[Louis LaBrunda]

Hi,

First be sure you have taken Jan's advice about setting the
#AllCallsThreaded preference in AbtDbmSystem to true.

Then see if you can drop the priority of a session with a long running
task.  This can be tricky as you may want to up the priority when the long
running task finishes.

And/Or you can relinquish the CPU in the middle (or elsewhere) of long
running tasks with "Processor yield".  It will move on to the next process
if and are ready or back to your long running process if it is the only
one.

Lou

On Tue, 10 Mar 2015 03:15:12 -0700 (PDT), wilwarin
<Ondrej.Altman at seznam.cz> wrote:

>Hi all,
>
>please excuse my inactivity, now I would like to summarize all above, and to
>ask you maybe for a few last answers and advices.
>
>Regarding to mentioned DB2, as I assumed, database is definitely not an
>issue, so I am sorry for my inaccuracy in my first post. At the moment we
>are sure that there is no block from the database side (we can see the block
>in data processing). Thank you guys for your solution proposals.
>
>
>> The only Seaside limitation I'm aware of is a lock around every 
>> session. So only one request of 'A' can be processed at any given 
>> time. However this should not affect any other users. The lock is 
>> there because sessions and components are mutable. Use the code from 
>> Sven to verify Seaside and your webserver are not the issue. 
>
>This is the behavior we assumed, this (max. one request per session at any
>time) has to be, and actually is, enough. However we are really surprised,
>that other users are affected. And by our investigation they are always
>affected by every concurrent request, no matter how difficult it is. 
>
>( I tried Sven's code and it is possible to do another work during waiting,
>it is OK. )
>
>
>> But that problem (not being able to process concurrent requests) is 
>> certainly not inherent to Seaside or Pharo. If that were the case we 
>> should all stop using it. 
>
>Hopefully I understand, so it is not the case. If I am correct, it means
>that in Seaside it is necessary to solve similar situations with different
>access. In case of for example difficult server-side calculation (or
>processing of big amount of data), we have to count on a possible problem
>with concurrent requests from multiple sessions. Am I right? Or, if not,
>where could the problem lay?
>
>As I wrote, we are working in VAST - I tried to simulate the same problem in
>Pharo with the same result, so I think in this case it does not matter much.
>Regarding to Apache (or, when we run it from code), everything is in default
>configuration. Database is not an issue. For me it looks like everything,
>that I wrote here, is a standard behavior of application build on Seaside =>
>the application which has to serve not-so-easy concurrent requests has to
>use some way around (multiple images & load balancing, parallelization of
>processes, ...). Please correct me if I am wrong.
>
>Guys, could you please tell me what I am missing?
>
>Maybe I can imagine, that the application we are developing is not a
>'standard' Seaside app (in the sense of data amount and its difficult
>server-side processing). Then I believe it would require a non-standard
>architecture (according to that all, is Seaside still the path we can/should
>follow?). It is our problem, we do not know about a reliable way to do that
>- and this is the reason, why I am asking here.
>
>What would you recommend? 
>
>Thank you again for your time, and thank you for your responses in advance.
>
>Cheers,
>Ondrej.
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:Lou at Keystone-Software.com http://www.Keystone-Software.com