[Seaside] Re: Concurrent requests from multiple sessions

Sven Van Caekenberghe sven at stfx.eu
Tue Mar 10 11:51:12 UTC 2015


Well, we can't help him unless he give us a reproducible case.

My code shows there is no such problem.

There might be some miscommunication going on, but from my cursory reading, I got the impression that he suggests there is a fundamental problem with something except his own code.

> On 10 Mar 2015, at 12:31, Nowak, Helge <HNowak at cincom.com> wrote:
> 
> Hmm,
> 
> I am sure Ondrej understood what was proposed. He mentioned at least twice that the DB connections are NOT the problem. He said that the processing AFTER loading the data from the database into the image is the problem. Why shouldn't I believe him? OTOH I believe you Seaside experts that Seaside's architecture is inherently non-blocking between sessions.
> 
> Thus there are two questions:
> - how could any processing block the whole Seaside image?
> - how to find possibly problematic spots in Ondrej's application code?
> 
> Once that is resolved one could think about further improvements.
> 
> Cheers
> Helge
> 
> -----Ursprüngliche Nachricht-----
> Von: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-bounces at lists.squeakfoundation.org] Im Auftrag von Sven Van Caekenberghe
> Gesendet: Dienstag, 10. März 2015 12:12
> An: Seaside - general discussion
> Betreff: Re: [Seaside] Re: Concurrent requests from multiple sessions
> 
> 
>> On 10 Mar 2015, at 11:15, wilwarin <Ondrej.Altman at seznam.cz> wrote:
>> 
>> ( I tried Sven's code and it is possible to do another work during 
>> waiting, it is OK. )
> 
> Does it also work (slowly) during the benchmark ?
> That simulates your 'long running work'.
> 
>>> 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?
> 
> What everybody here tries to explain to you is that the problem is most probably in your DB driver (in Smalltalk or further down): it probably cannot do more than one concurrent request (as it is currently implemented). That is not a Seaside nor a fundamental Smalltalk problem.
> 
> Try investigating that aspect, separate from Seaside._______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside



More information about the seaside mailing list