Kbase 16950: Web Developers Must Maintain Context Between Web Requests
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Web Developers Must Maintain Context Between Web Requests
Web application development differs from client-server and
host-based development in that context information, such as changes
to PROPATH or modification of the list of connected databases are not
automatically preserved between the submission of web requests.
Another way to say this is that web applications are generally
'pseudo-conversational'. That is, while it looks to the end-user like
s/he is having a 'conversation' with the host computer, in reality
context of the conversation is lost each time a request is made to the
web server, unless the application developer takes steps to preserve
context by using 'cookies', STATE-AWARE procedures and/or database
modifications to preserve this context.
For example, if a broker is started attached to the WebSport
database, the agents managed by that broker are all started with a
connection to the WebSport database. Any web request that comes in
will be fulfilled by an agent that is connected to the WebSport
database. If User 1 submits a web request that is handled by
Agent A, and the request has a 'DISCONNECT WebSport' statement in it,
ONLY THE AGENT IN USE FOR THAT REQUEST WILL BE DISCONNECTED FROM THE
WEBSPORT DATABASE. When User 2 submits a web request, that request
*may* be handled by Agent A, or it may be handled by a different agent
agent. At this point, neither User 1 nor User 2 can rely on finding
the same set of databases open when the next web request is made.
User 2 may be particularly baffled by this.
Making web objects STATE-AWARE enables a user to lock a web agent.
This guarantees that context will be preserved for all subsequent
requests until the agent is unlocked. By using a state-aware web
object, an application can change PROPATH or connected databases in
its Main Code Block (which is run when the object is created) and
these changes will persist across web requests. However, it should
also reset any values it has changed in a local-destroy
procedure.
Other 4GL statements that fall into this category are:
SESSION:NUMERIC-FORMAT
SESSION:DATE-FORMAT
CREATE ALIAS...
DELETE ALIAS...
RUN ... PERSISTENT SET ...
Any variables or attributes that are GLOBAL to a WebSpeed session.
A final point is that while we don't recommend that you do this, you
can do it if you need to, providing all your procedures are aware of
the situation.
For example, suppose you need a specific persistent procedure to
run on all agents for one piece of your application, but you don't
want to modify the startup procedure so that it is always there. You
could add the following lines to all files that rely on this
persistent procedure.
DEFINE VARIABLE h_special AS HANDLE NO-UNDO.
IF NOT VALID-HANDLE (h_special)
THEN
RUN special.p PERISTENT SET h_special.
This would mean that the first time an agent runs across this code,
it will start the persistent process. The next time the same agent
sees this code, it will use the in-memory version (rather than
starting a new copy).
This would be useful for a persistent procedure that defined
FUNCTIONS or INTERNAL PROCEDURES that you wanted access to. It could
not be used for storing "persistent" variables because there is no
guarantee that the next web request would be to the same agent.
Progress Software Technical Support Note # 16950