2010/12/2 Michael Van Canneyt <[email protected]>: > > > On Thu, 2 Dec 2010, Marcos Douglas wrote: > >> On Thu, Dec 2, 2010 at 1:12 PM, <[email protected]> wrote: >>> >>> >>> On Thu, 2 Dec 2010, Dariusz Mazur wrote: >>> >>>> W dniu 2010-12-02 11:38, [email protected] pisze: >>>>> >>>>> >>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote: >>>>> >>>>>> W dniu 2010-12-02 09:25, [email protected] pisze: >>>>>>> >>>>>>> >>>>>>> On Thu, 2 Dec 2010, Dariusz Mazur wrote: >>>>>>> >>>>>>>> >>>>>>>>>> ExtPascal uses threads to handle multiple connections. I remember >>>>>>>>>> you >>>>>>>>>> don't accept this way, right? BTW, what is there wrong if >>>>>>>>>> ExtPascal >>>>>>>>>> uses threads? >>>>>>>>> >>>>>>>>> I accept using threads, but not the way ExtPascal does it. Threads >>>>>>>>> should be >>>>>>>>> optional. In extpascal, the thread is equal to the session: if you >>>>>>>>> have many >>>>>>>>> sessions, the application will create as many threads as there are >>>>>>>>> sessions. >>>>>>>> >>>>>>>> I use different architecture: each session has own thread and each >>>>>>>> connection has own thread. Sessions are separated from connections and >>>>>>>> communicate via FIFO queue. >>>>>>>> Session runs whole life time in the same thread. With this i can use >>>>>>>> modal form and thread var in the same manner, as normal (desktop) >>>>>>>> application. >>>>>>> >>>>>>> I understand this is the easy way. >>>>>>> >>>>>>> But you don't need this architecture to do that. As long as a single >>>>>>> request >>>>>>> runs in a single thread, there is no problem with decoupling sessions >>>>>>> and >>>>>>> threads, and still be able to keep everything in memory. >>>>>> >>>>>> I dont understand. >>>>>> I parse single request in single thread (for each request new thread) >>>>>> and what can I do (other) with sessions? >>>>> >>>>> One scenario looks like this: >>>>> - Request comes in (on whatever thread). >>>>> - Determine session data (your form) for the request. >>>>> Session data is in a global list. >>>>> - Find a thread to handle the request. >>>>> - Pass session data to thread and let it handle request. >>>>> >>>>> Another way is >>>>> - Connection is accepted. >>>>> - An idle thread to handle request is found. >>>>> - Thread looks up session data from data in request. >>>>> - Thread handles request using found session data. >>>>> >>>> >>>> At the beginning I use second attempt, after that first. But both have >>>> limitation, because not follow (not act as desktop OS) desktop >>>> architecture. >>>> There are not pass to more complicated application (when it is porting >>>> from Delphi). >>>> >>> >>> This is correct, but I assume that when starting a web application, you >>> will start with a fresh design. >>> >>>> 1. All task of application should be prepare as response for request, >>>> there is problem with modal forms, which stop and wait to user action, and >>>> after response go on (next statement in current procedure, not other ). >>>> 2. When application is busy for long time with preparing response, its >>>> no chance to make simple response with message of waiting (or progress bar) >>> >>> I don't see the connection of these problems with how threads are used. >>> A simple WaitForEvent()/SetEvent() should do this. >>> >>>> 3. With second attempt session data is computing with different threads, >>>> thus thread vars can't be used >>> >>> They are only a problem if you use global variables. You should never use >>> global variables, unless maybe the database connection and global >>> application configuration. >>> >>> None of my 4 web applications uses global variables (except said database >>> connection and global configuration object). The other programmers have >>> not yet complained. They know global variables >>> are evil from their work on our regular desktop program :-) >> >> How do you work to manipulate sessions? > > There is a global sessionlist (simple hashlist: string is session GUID, > object is session module). > based on the session cookie, I get the session. All other things are stored > in a descendent of the session module.
There is just a global sessionlist accessed for many threads, at the same time? The fpWeb framework manages thread conflicts? Marcos Douglas -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
