Thanks for all the answers. To summarize: - session will lock unless the controller calls session._unlock() or session.forget() - database locking may also occur
In my case, when calling (ajax) the same controller function with different parameters, the requests would be handled sequentially. Add a "session.forget()" at the begin of the controller function, it seemed to me the requests were still handled sequentially, BUT it wasn't the case! The reason why is simple: my controller function makes a call to the Google Analytics API and... those requests are not handled concurrently! :-( (Google Analytics has some weird limitation quotas, limiting to 4 concurrent calls per IP address | see here if interested: http://code.google.com/apis/analytics/docs/gdata/gdataDeveloperGuide.html#quota ) For small size api requests (for which the answer from the Google Analytics server is response is fast), it works but for large requests (which is my case), it seems Google Analytics doesn't always handle those 4 requests concurrently! There is the origin of the confusion. So, no bug on the web2py side! I checked it: Rocket is able to handle concurrent request from the same user, if session and db connections are not locked. Thank everyone again for all the answers and insight! Lesson of the day: don't take Google's word for granted when saying their API handles 4 requests concurrently... :-( On Mar 24, 4:59 pm, John Heenan <johnmhee...@gmail.com> wrote: > On Mar 22, 7:37 am, olivier <odema...@gmail.com> wrote: > > > I plan to use web2py as a simple desktop app service (using the > > packaged web2py for windows). > > Will the web server (I don't know which server ships in the stand > > alone version) handle several requests in parallel if I use ajax calls > > to several controller functions? > > Depends on what you mean by parallel. > > In normal terms, that is if you are not depending on some state or > property that requires use of artifically managed parallel > transactions, the answer is yes. > > Why not just test and see? > > There are practical limits. A severe practical limit comes form the OS > overhead in using a thread for each web2py request to a controller > function. > > The mentioned session and database locking issues are of course also > relevant. Just beacuse a session or database locks occurs does not > mean the request fails. They are just one more place queues or locks > occur. IO (input-output) OS (operating systems) queues or locks are > very common and are hidden. > > I hope this adds a bit more insight. > > John Heenan
