|
|
|
|
|
Session Management Continued from Diagram: How LiveConnect Works Session Management service manages requests and maintains state information. The service consists of five objects: request, client, project, server, and Lock. To understand these objects, you need to understand how they are used and when they are created in the runtime environment. Request is the shortest-lived of the session management objects, lasting only for the duration of a single client request. Typically, client requests occur when a user enters a URL or clicks on a hyperlink. You can use request to examine information sent in client requests, such as the data submitted in a form, or to examine information about the client and the client request, such as the type of client being used. To manage user sessions and maintain state information, you will rely on the client object. Client maintains user-specific information across multiple requests. Although many different users can access an application simultaneously, each user has a unique client object for that application. Further, users always have different client objects for different applications--even if those applications are running on the same server. You can use client to maintain user preferences, such as settings for colors and fonts, or users' account information, such as user names, passwords, and account numbers. The runtime engine actually creates and destroys client objects with each request. By destroying client objects that are not currently in use, the runtime engine saves system resources--notably memory. You can't restore a client object at the beginning of each request without client-maintenance techniques such as cookies or URL-encoding. Often you will need to pass information among clients and applications. You do this with the project and server objects. Project maintains state information for multiple clients using a particular application; server maintains state information for multiple applications running on a particular server. These objects are often used in conjunction with Lock, which lets you control access to a section of code temporarily. You can use project to track any properties or values related to a single application. Application administrators may need to obtain current usage summaries, such as the current number of users or the average number of transactions per hour. Project can also handle real-time interactions among users, of the sort online chat programs require. A new project object is created each time you start an application, and the object is destroyed any time you stop or restart an application. Because a single server can have multiple separate instances of an application, each instance of an application has its own unique project object. Server objects let applications share information. For example, as a user moves from one application to another, server can pass on the user's preferences and login information. A server object is created when the server process is started and destroyed when the server process is stopped. All applications using the same server process share the same server object. Any time a host machine runs multiple server processes on different ports there will be multiple server objects. These objects will correspond to the specific server processes and ports they answer on. For example, a server process on port 80 will have a different server object than a server process on port 8080. Netscape's server provides a multithreaded environment for JavaScript applications. Though multithreading speeds up processing and improves performance, it can lead to conflicts over which process has control of an application's objects and properties at any given time. To prevent this, an application should control access to the project and server objects. The application can handle access controls using either explicit locking or an instance of the Lock object. With explicit locking, project and server are locked by invoking their respective Lock() methods. Lock() blocks access to the object until unlock() is called. Unfortunately, there is no time-out built in, so users can be locked out of the entire application if unlock() isn't invoked. As this isn't optimal, you may want to create an instance of the Lock object instead. With Lock, you control not only access to a key section of code but also how long the lock lasts and which objects and properties it affects. Next: File and Mail Services Published as PC Tech Feature in the 5/4/99 issue of PC Magazine. Related Links |
||||||||||||||
|
|||||||||||||||||||||||||||||||||||||
| TOP | 
Copyright (c) 1999 Ziff-Davis Inc. |
