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