[Seaside] Concurrent requests from multiple sessions

[Sean Glazier]

I would make a specialized DB 2 interface in c that makes the request in an OS thread that the signals the vast vm when the result is in. Your vast vm will not then block preventing the processing of the DB 2 request. In visual works we have thappi precisely because of these DB and other blocking issues. You can make a similar system for vast c calls only you will need to generalize a solution to give rhe needed information for the call and the data. You can spike a solution easily enough for the DB 2 calls by creating a dll of the same name that vast loads rather than the DB 2 dll. You dll starts up a thread pool and forwards the call in a new thread. You will need to coordinate your response etc so you are not blocking the vm thread allowing it to respond to other seaside sessions.

Sean

Sent from my iPhone
Sean Glazier
Light your self on fire with Enthusiasm and people will come for miles around to watch you burn!

On Mar 6, 2015, at 15:55, Sven Van Caekenberghe <sven at stfx.eu> wrote:

> 
>> On 06 Mar 2015, at 11:17, wilwarin <Ondrej.Altman at seznam.cz> wrote:
>> 
>> We didn't know, where our problem lies, so we tried a similar test with a
>> single page with a difficult calculation inside. Then we tried the same in
>> Pharo to exclude the problem in VAST. Both with the same results.
> 
> I just tried the following on Pharo 4 with Seaside 3.1, in a WATask
> 
> go
>  self inform: 'WATest1 ready.'.
>  (self confirm: 'Wait 30s ?')
>    ifTrue: [ 
>      (self confirm: 'Do some benchmarking ?')
>        ifTrue: [ 
>          self inform: ([ 100 factorial ] benchFor: 30 seconds) asString ]
>        ifFalse: [ 
>          30 seconds wait.
>          self inform: 'Back from waiting 30s' ] ]
>    ifFalse: [ self inform: 'OK then, I did not wait' ]
> 
> In both cases, you can do other work during the 30s. Of course, things will get quite slow during the benchmarking, but that is logical since you are pushing the machine 100%, consuming all CPU power.
> 
> Like Jan suggests, some DB interfaces are blocking, effectively killing (serialising) multiprocessing. I know that PostgresV2 is not like that, since it uses a TCP networking interface.
> 
> 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.
> 
> Sven
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside