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? Marcos Doulglas -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
