I must first admit I haven’t inspected your source code that much, only tried to read the documentation.
Anyhow, I am curious if there can come any problems out of same application running on different threads. Based on what I’ve understood of the servlet model, server-side programs do not have much to say on which thread their requests are served.
As all ‘events’ are implemented as callbacks and not on some shared event queue, this can lead to situations where two different threads run same user’s application and touch the same data. This again can cause data corruption and other bad things.
So have I understood the premises wrong, is the probability of this happening negligible small or do is lots and lots of synchronization required? I’d think that the last one is not the case as I haven’t seen much of synchronization used in your classes.
In short, the request handing is synchronized per application; if a user sends two requests at once to the same application, they’re handled one at a time.
Note that if you want to do some heavy processing, but allow the user to continue working with the application, you should start a separate ‘processing’ thread, and handle synchronization as appropriate for the resources it uses.
So we’re not counting on probabilities, but we’re not synchronizing all over the place either
Feel free to look at the code if you want to understand the method we’re using better.
We also periodically run extensive robustness tests which involve bombing same application with 100-200 concurrent threads with zero wait. This typically demonstrates tens of thousands of different concurrent users per server. First version of 5.0.0 had some synchronization issues but if I remember correctly these were fixed within first few maintenance releases quite quickly.
Based on above comment and Marc’s, I’d say Toolkit has this case covered well
