Title: Mechanism for enabling session information to be shared across multiple processes
Abstract: A mechanism for enabling session information to be shared across multiple processes in a multi-process environment is disclosed. There is provided a shared persistent memory-mapped file in a file system, which is mapped to the memory space of each of the processes. This file is used by all of the processes to store session information. Because the memory space of each process is mapped to the shared file, each process is able to access and manipulate all of the sessions in the system. Thus, sessions are no longer maintained on a process-specific basis. Rather, they are maintained on a centralized, shared basis. As a result, different requests pertaining to the same session may be serviced by different server processes without any adverse effects. Each process will be able to access and manipulate all of the state information pertaining to that session. By enabling session information to be shared, this mechanism eliminates the session management errors experienced by the prior art.
Patent Number: 6,938,085 Issued on 08/30/2005 to Belkin, et al.
| Inventors:
|
Belkin; Ruslan (Mountain View, CA);
Ramachandran; Viswanath (Mountain View, CA)
|
| Assignee:
|
Sun Microsystems, Inc. (Palo Alto, CA)
|
| Appl. No.:
|
574398 |
| Filed:
|
May 19, 2000 |
| Current U.S. Class: |
709/227; 709/312; 709/228; 709/215; 709/213; 709/214; 711/205 |
| Intern'l Class: |
G06F 015/16 |
| Field of Search: |
709/227,312,228,215,213,214,217
711/205
|
References Cited [Referenced By]
U.S. Patent Documents
| 5329589 | Jul., 1994 | Fraser et al.
| |
| 5410698 | Apr., 1995 | Danneels et al.
| |
| 5530852 | Jun., 1996 | Meske, Jr. et al.
| |
| 5586312 | Dec., 1996 | Johnson et al.
| |
| 5691973 | Nov., 1997 | Ramstrom et al.
| |
| 5752031 | May., 1998 | Cutler et al.
| |
| 5790790 | Aug., 1998 | Smith et al.
| |
| 5793415 | Aug., 1998 | Gregory, III et al.
| |
| 5796393 | Aug., 1998 | MacNaughton et al.
| |
| 5809145 | Sep., 1998 | Slik et al.
| |
| 5809248 | Sep., 1998 | Vidovic.
| |
| 5835724 | Nov., 1998 | Smith.
| |
| 5872963 | Feb., 1999 | Bitar et al.
| |
| 5913029 | Jun., 1999 | Shostak.
| |
| 5918228 | Jun., 1999 | Rich et al.
| |
| 5928323 | Jul., 1999 | Gosling et al.
| |
| 5961584 | Oct., 1999 | Wolf.
| |
| 5991792 | Nov., 1999 | Nageswaran.
| |
| 6012090 | Jan., 2000 | Chung et al.
| |
| 6014666 | Jan., 2000 | Helland et al.
| |
| 6052711 | Apr., 2000 | Gish.
| |
| 6058460 | May., 2000 | Nakhimovsky.
| |
| 6076108 | Jun., 2000 | Courts et al.
| |
| 6088728 | Jul., 2000 | Bellemore et al.
| |
| 6098093 | Aug., 2000 | Bayeh et al.
| |
| 6112196 | Aug., 2000 | Zimowski et al.
| |
| 6125382 | Sep., 2000 | Brobst et al.
| |
| 6128644 | Oct., 2000 | Nozaki.
| |
| 6141684 | Oct., 2000 | McDonald et al.
| |
| 6163801 | Dec., 2000 | O'Donnell et al.
| |
| 6182109 | Jan., 2001 | Sharma et al.
| |
| 6209018 | Mar., 2001 | Ben-Shachar et al.
| |
| 6237024 | May., 2001 | Wollrath et al.
| |
| 6249844 | Jun., 2001 | Schloss et al.
| |
| 6253239 | Jun., 2001 | Shklar et al.
| |
| 6260077 | Jul., 2001 | Rangarajan et al.
| |
| 6266661 | Jul., 2001 | Lewish et al.
| |
| 6304967 | Oct., 2001 | Braddy.
| |
| 6314093 | Nov., 2001 | Mann et al.
| |
| 6317742 | Nov., 2001 | Nagaratnam et al.
| |
| 6336135 | Jan., 2002 | Niblett et al.
| |
| 6338064 | Jan., 2002 | Ault et al.
| |
| 6343328 | Jan., 2002 | Murphy, Jr. et al.
| |
| 6374286 | Apr., 2002 | Gee et al.
| |
| 6377999 | Apr., 2002 | Bartas.
| |
| 6393477 | May., 2002 | Paxhia et al.
| |
| 6397253 | May., 2002 | Quinlan et al.
| |
| 6415329 | Jul., 2002 | Gelman et al.
| |
| 6418458 | Jul., 2002 | Maresco.
| |
| 6490624 | Dec., 2002 | Sampson et al.
| |
| 6542920 | Apr., 2003 | Belkin et al.
| |
| 6549996 | Apr., 2003 | Manry et al.
| |
| 6557038 | Apr., 2003 | Becker et al.
| |
| 6564252 | May., 2003 | Hickman et al.
| |
| 6604125 | Aug., 2003 | Belkin.
| |
| 6629130 | Sep., 2003 | Mertama et al.
| |
| 2004/0064564 | Apr., 2004 | Belkin.
| |
Other References
"System for Dispatching from Multiple Thread Pools", Jan. 1, 1998, IBM Technical
Disclosure Bulletin, vol. 41, issue No. 1, pp. 329-332.
Sebastian Wilhelmi, "Re: (ORBit-mt-0.5.7)g_main_iterate():main loop already active
in another thread," Jan. 28, 2002, http://mail.gnome.org/archives/orbit-list/2002-January/msg00152.html,
printed Oct. 21, 2002, 2 pages.
Sumedh Mungee, "Online CORBA documents," http://www.cs.wustl.edu/˜schmidt/CORBA-docs/,
printed Oct. 21, 2002, 3 pages.
|
Primary Examiner: Maung; Zarni
Assistant Examiner: Halim; Sahera
Attorney, Agent or Firm: Nicholes; Christian A., Hickman Palermo Truong & Becker LLP
Parent Case Text
This application claims the benefit of U.S. Provisional Application entitled
"Web Server Architecture", No. 60/156,305, filed Sep. 24, 1999, and U.S. Provisional
Application entitled "Web Server Architecture", No. 60/155,711, filed Sep. 24,
1999. This application is also a continuation-in-part of U.S. patent application
entitled "Mechanism for Enabling Customized Session Managers to Interact with a
Network Server", Ser. No.09/524,775, now U.S. Pat. No. 6,701,367, filed on Mar.
14, 2000. The entire contents of these prior applications are hereby incorporated
by reference.
Claims
1. A computer system, comprising:
a memory-mapped file;
a first server process, said first server process servicing a first request pertaining
to a particular session, said first server process storing session information
pertaining to said particular session in said memory-mapped file; and
a second server process, said second server process servicing a second request
pertaining to said particular session, said second server process accessing said
session information from said memory-mapped file and using said session information
to service said second request;
wherein said memory-mapped file is mapped to at least a portion of a virtual
memory space of said first server process and at least a portion of a virtual memory
space of said second server process.
2. The system of claim 1, wherein said first server process stores said session
information into said memory-mapped file in the form of a serialized byte stream.
3. The system of claim 2, wherein said second server process deserializes said
serialized byte stream prior to using said session information to service said
second request.
4. The system of claim 1,wherein said second server process sets a busy indicator
associated with said session information to indicate that said session information
is currently in use, thereby preventing any other server process from using said
session information while said second server process is using said session information.
5. The system of claim 1, wherein said second server process updates said session
information to derive a set of updated session information, and wherein said second
server process stores said updated session information in said memory-mapped file.
6. The system of claim 5, wherein said updated session information replaces said
session information in said memory-mapped file.
7. The system of claim 6, further comprising:
a third server process, said third server process servicing a third request pertaining
to said particular session, said third server process accessing said updated session
information from said memory-mapped file and using said updated session information
to service said third request.
8. A computer-implemented method for servicing requests, comprising:
instantiating a first server process;
instantiating a second server process;
receiving a first request pertaining to a particular session;
servicing said first request with said first server process, said first server
process storing session information pertaining to said particular session in a
memory-mapped file;
receiving a second request pertaining to said particular session; and
servicing said second request with said second server process, said second server
process accessing said session information from said memory-mapped file and using
said session information to service said second request;
mapping at least a portion of a virtual memory space of said first server process
to said memory-mapped file; and
mapping at least a portion of a virtual memory space of said second server process
to said memory-mapped file.
9. The method of claim 8, wherein said first server process stores said session
information into said memory-mapped file in the form of a serialized byte stream.
10. The method of claim 9, wherein said second server process deserializes said
serialized byte stream prior to using said session information to service said
second request.
11. The method of claim 8, wherein servicing said second request comprises:
setting a busy indicator associated with said session information to indicate
that said session information is currently in use, thereby preventing any other
server process from using said session information while said second server process
is using said session information.
12. The method of claim 8, wherein servicing said second request comprises:
updating said session information to derive a set of updated session information;
and
storing said updated session information into said memory-mapped file.
13. The method of claim 12, wherein storing said updated session information
into said memory-mapped file comprises: overwriting said session information with
said updated session information.
14. The method of claim 13, further comprising:
instantiating a third server process;
receiving a third request pertaining to said particular session; and
servicing said third request with said third server process, said third server
process accessing said updated session information from said memory-mapped file
and using said updated session information to service said third request.
15. A computer readable medium having stored thereon instructions which, when
executed by one or more processors, cause the one or more processors to service
requests, said computer readable medium comprising
instructions for causing one or more processors to instantiate a first server
process;
instructions for causing one or more processors to instantiate a second server
process;
instructions for causing one or more processors to receive a first request pertaining
to a particular session;
instructions for causing one or more processors to service said first request
with said first server process, said first server process storing session information
pertaining to said particular session in a memory-mapped file;
instructions for causing one or more processors to receive a second request pertaining
to said particular session; and
instructions for causing one or more processors to service said second request
with said second server process, said second server process accessing said session
information from said memory-mapped file and using said session information to
service said second request;
instructions for causing one or more processors to map at least a portion of
a virtual memory space of said first server process to said memory-mapped file;
and
instructions for causing one or more processors to map at least a portion of
a virtual memory space of said second server process to said memory-mapped file.
16. The computer readable medium of claim 15, wherein said first server process
stores said session information into said memory-mapped file in the form of a serialized
byte stream.
17. The computer readable medium of claim 16, wherein said second server process
deserializes said serialized byte stream prior to using said session information
to service said second request.
18. The computer readable medium of claim 15, wherein the instructions for causing
one or more processors to service said second request comprises:
instructions for causing one or more processors to set a busy indicator associated
with said session information to indicate that said session information is currently
in use, thereby preventing any other server process from using said session information
while said second server process is using said session information.
19. The computer readable medium of claim 15, wherein the instructions for causing
one or more processors to service said second request comprises:
instructions for causing one or more processors to update said session information
to derive a set of updated session information; and
instructions for causing one or more processors to store said updated session
information into said memory-mapped file.
20. The computer readable medium of claim 19, wherein the instructions for causing
one or more processors to store said updated session information into said memory-mapped
file comprises:
instructions for causing one or more processors to overwrite said session information
with said updated session information.
21. The computer readable medium of claim 20, further comprising:
instructions for causing one or more processors to instantiate a third server
process;
instructions for causing one or more processors to receive a third request pertaining
to said particular session; and
instructions for causing one or more processors to service said third request
with said third server process, said third server process accessing said updated
session information from said memory-mapped file and using said updated session
information to service said third request.
Description
BACKGROUND
This invention relates generally to computer systems, and more particularly
to a mechanism for enabling session information to be shared across multiple processes.
On the Internet or World Wide Web, information is generally communicated on a
request-response basis. That is, a client (typically running a browser program)
submits a service request to a server. The service request may simply ask for a
static page (usually in HTML format), or it may request that a particular application
or program be executed to generate a return page. In response to the service request,
the server performs whatever tasks are necessary to service the request, and provides
a response page to the client. This request-response sequence, referred to as a
"roundtrip", is carried out for each request.
For simple applications in which every task that needs to be performed can be
carried out single roundtrip, statelessness is not a problem. However, for exchanges
(such as transactions) that require multiple roundtrips, the lack of state presents
a significant impediment.
An example of an application in which it is necessary to maintain state across
multiple roundtrips is that of an "electronic shopping cart" application. More
specifically, a user visits a merchant's website using a particular client machine.
As the user peruses the website, he sees an item that he wishes to purchase, and
puts that item into his "shopping cart". As some point, the user invokes a link
to another page of the website, and at that point, a request is sent to the server
which requests the desired page and which also provides to the server all of the
items currently in the shopping cart. The server responds to the request by storing
information pertaining to the shopping cart items, and by providing the desired
page to the client. Thereafter, the user peruses the new page and puts additional
items into the shopping cart. In a subsequent request by the client, the additional
items in the shopping are sent to the server. Since the subsequent request is from
the same client, the server should associate the additional items with the previous
items as being in the same shopping cart. To do this, though, the server needs
to associate the subsequent request with the previous request, which in turn requires
that the server maintain state information relating to the requests. However, as
noted above, the Internet is generally a stateless environment. As a result, without
further functionality on the part of the server, multiple roundtrip exchanges,
such as those required by the electronic shopping cart application, cannot be implemented
on the Internet.
To enable exchanges involving multiple roundtrips to be carried out, some servers
implement session management functionality. Basically, this functionality maintains
session information across multiple roundtrips so that associations between multiple
requests can be made. As used herein, the term session information refers broadly
to any information, including state information, which can be used to relate one
request with another request. Usually, state information is maintained by passing
session ID information back and forth between the client and the server. For example,
when a service on the server requiring state information is first invoked by a
client request, a new session is created, and a new session ID is associated with
the new session. The session acts as a "container" to store all of the necessary
state information relating to that particular session. Once the session is created
(and possibly updated to include state information relating to processing of the
current request), the associated session ID is provided to the client that requested
the service. If that client makes a subsequent request to the same service, the
client includes in that request the session ID. Using the session ID, the server
accesses the associated session, and based upon the state information stored in
the associated session, the server can determine what has transpired thus far.
In this manner, the server is able to associate a current request with one or more
previous requests.
Typically, the session management functionality of a server is process-specific.
That is, each instance of the server (with each instance being its own process)
maintains session information for its own sessions, and only that process can access
and manipulate that session information. This is not a problem if there is only
one instance of the server, or if it is guaranteed that the same server instance
will service all of the requests pertaining to a particular session. However, where
there are multiple instances of the server, and there are no guarantees that the
same instance will receive all of the requests pertaining to a particular session,
this process-specific limitation of the session management functionality can lead
to serious errors.
To illustrate, suppose that there are two instances of a server (i.e. two server
processes) running in a particular system, and that requests are distributed to
these two server processes in a round-robin fashion. In such a system, it is quite
possible for two requests pertaining to the same session to be processed by two
different server processes. If that occurs, processing errors may and most likely
will occur.
For example, suppose that the first request of a transaction is received and
processed by a first server process. In response to this request, the first server
process creates a new session, and assigns that new session a session ID. This
session ID is returned to the client submitting the request. Suppose further that
that same client submits a second request pertaining to the same session, and includes
in the second request the session ID that was received from the first server process.
Suppose, however, that this second request is received not by the first server
process but by a second server process. Because the second server process cannot
access the session information of the first server process, it cannot carry on
processing of the transaction in the same manner as the first server process. Instead,
the second server process may respond in one of several different ways. First,
the second server process may simply not recognize the session ID, in which case,
it creates a new session and a new session ID. If this occurs, then the same transaction
will have two different sessions (one on each server process), with neither session
containing all of the state information for the entire transaction. This clearly
is not a desirable result. Worse yet, the second server process may recognize the
session ID (but this session ID will be associated with another session completely
unrelated to the transaction pertaining to the request), and use the state information
in that session to service the request. If that occurs, not only will errors arise
in servicing the current request, but the data for the other session will also
be corrupted. As this discussion shows, the process-specific limitation of the
session management functionality can lead to serious errors in a multi-process
environment. As a result, an improved mechanism for implementing session management
in a multi-process environment is needed.
SUMMARY OF THE INVENTION
In light of the shortcomings of the prior art, the present invention provides
a mechanism for enabling session information to be shared across multiple processes
in a multi-process environment. In one embodiment, there is provided a shared persistent
memory-mapped file in a file system which is mapped to the memory space of each
of the processes. This file is used by all of the processes to store session information.
Because the memory space of each process is mapped to the shared file, and because
each process uses the shared file to stored session information, each process will
be able to access and manipulate all of the sessions in the system. Thus, sessions
are no longer maintained on a process-specific basis. Rather, they are maintained
on a centralized, shared basis. As a result, different requests pertaining to the
same session may be serviced by different server processes without any adverse
effects. Each process will be able to access and manipulate all of the state information
pertaining to that session. By enabling session information to be shared across
multiple processes, the present invention eliminates the session management errors
experienced by the prior art. Thus, the present invention provides an improved
mechanism for managing session information in a multi-process environment.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a functional block diagram of a system in which one embodiment of
the present invention may be implemented.
FIG. 2 is a diagram of one possible embodiment for the shared file of FIG. 1.
FIG. 3 is a logical block diagram illustrating the process by which multiple
server processes are instantiated and mapped to the shared file of FIG. 1.
FIG. 4 is a functional block diagram of one possible embodiment of a server
process in accordance with one embodiment of the present invention.
FIG. 5 is an operational flow diagram for the server process of FIG. 4.
FIG. 6 is a hardware block diagram of a computer system in which one embodiment
of the present invention may be implemented.
DETAILED DESCRIPTION OF EMBODIMENT(S)
With reference to FIG. 1, there is shown a functional block diagram of a system
100 in which one embodiment of the present invention may be implemented,
the system comprising a client
102, a network
104, and a server system
106. For the sake of simplicity, only one client
102 is shown; however,
it should be noted that multiple clients
102 may be coupled to, and communicate
with, the server system
106 via the network
104. For purposes of
the present invention, the client
102 may be any mechanism capable of communicating
with the server system
106, including but not limited to a computer running
a browser program. The client
102 may communicate with the server system
106 using any known protocol, including but not limited to HTTP and FTP.
The network
104 may be any type of network, including but not limited
to a local area network and a wide area network such as the Internet. The network
104 may even be as simple as a direct connection. Any mechanism capable
of facilitating communication between the client
102 and the server system
106 may serve as the network
104.
The server system
106 is the component responsible for providing most
of the functionality of the system
100. More specifically, the server system
106 receives requests from the client
102, and responds to the requests
by providing response pages. The response pages may be derived by simply accessing
static files, or by executing one or more applications to dynamically generate
the response pages. The term application is used broadly herein to refer to any
type of program or routine that is capable of performing one or more particular
functions. What actions need to be carried out by the server system
106
to derive the response pages is typically specified in the requests. Each request-response
sequence is referred to as a roundtrip.
As shown in FIG. 1, the server system
106 comprises a plurality of server
processes
108. Each server process
108 represents a particular instance
of a server, and each instance
108 is fully capable of servicing requests
from the client
102. It has been found that running multiple instances of
a server
108 concurrently in a system gives rise to certain advantages.
These advantages include the ability to load balance across the different server
processes
108, and the ability for one server process
108 to seamlessly
service the requests of another server process should that other process become disabled.
In a multi-process system such as that shown in FIG. 1, requests are distributed
among the various server processes
108 for servicing. In one embodiment,
the requests are distributed by an operating system
112. For purposes of
the present invention, the operating system may be any operating system, including
but not limited to UNIX, Solaris, and Windows NT. The operating system
112
distributes requests by first monitoring one or more ports (not shown) of the server
system
106 for incoming client requests. When a client request is detected,
it is assigned to one of the server processes
108 for servicing. In determining
to which server process
108 the request is to be assigned, the operating
system
112 may implement any desired distribution scheme. For example, the
operating system
112 may assign requests to the server processes
108
according to a round-robin scheme, a load-based scheme, or a priority-based scheme,
to name a few. For purposes of the present invention, any distribution scheme may
be used. Because incoming requests may be distributed to the server processes
108
according to any desired scheme, there is no guarantee that any particular server
process
108 will receive all of the requests pertaining to a particular
session. Thus, there is a good likelihood that the multiple requests pertaining
to a particular session will be serviced by different server processes
108.
To accommodate this possibility, the present invention implements the shared file
110 of FIG.
1.
In one embodiment, the shared file
110 takes the form of a memory-mapped
file in a file system, which is mapped to the memory space of each of the server
processes
108. This file
110 is used by each of the processes
108
to store session information. Because this file
110 is used by all of the
processes
108 to store session information, and because it is mapped to
the memory space of each of the server processes
108, each process
108
will be able to access and to manipulate the session information for all of the
sessions in the server system
106. Thus, session information is no longer
maintained on a process-specific basis. Rather, it is maintained on a centralized,
shared basis. Because session information is maintained on a shared basis, any
process
108 will be able to service any request pertaining to any session
without losing any session information or corrupting any session data. Thus, by
sharing session information across multiple processes, the present invention makes
it possible to effectively and safely implement session management in a multi-process
environment. In one embodiment, the shared file
110 is maintained as a persistent
file. That is, it is stored persistently such that if one or even all of the server
processes
108 are terminated, the file
110 is not eliminated. As
a persistent file, it may be stored in memory, on mass storage such as a hard drive,
or both.
In one embodiment, the shared file
110 takes the form show in FIG. 2,
comprising
an index portion
202 and a data portion
204. The index portion
202
contains information for facilitating access to the data portion
204, and
the data portion
204 contains the actual session information. In one embodiment,
the data portion
204 is divided into a plurality of fixed-sized data buckets
206, with each data bucket
206 (if that bucket is being used to hold
session information) being associated with a particular session ID, and each bucket
storing session information for a particular session. In addition to storing actual
session information, each data bucket
206 also stores a busy flag
208.
When set, this flag
208 indicates that a particular set of session information
is currently in use (i.e. that a request pertaining to that session is currently
being serviced). As will be explained further below, busy flag
208 may be
used by the server processes
108 to prevent more than one process
108
from working on a session at a time.
The associations between the buckets
206 and the session ID's are stored
in the index portion
202. In one embodiment, the associations are stored
in the form of a table comprising a session ID column
210 and a data bucket
column
212. The session ID column
210 stores a particular session
ID, and the data bucket column
212 stores a reference to one of the data
buckets
206 with which a particular session ID is associated. A session
ID may be associated with more than one data bucket
206 if one data bucket
is not large enough to hold all of the session information for a particular session.
To facilitate access to the data buckets
206, the index table is indexed
by session ID. Thus, the data buckets
206 are accessed based upon session
ID's. The shared file
110 is used by all of the server processes
108
to store and to retrieve all session information. The manner in which this is done
will be discussed in detail in a later section.
As mentioned above, the shared file
110 is memory-mapped to the memory
space of each of the server processes
108. In one embodiment, this is done
during system startup up using a particular initialization process. With reference
to FIG. 3, this process will be described in greater detail. During system start-up,
a number of initialization operations are performed. These operations may be grouped
into two sets: an early set; and a late set. In one embodiment, the early set of
initialization operations is performed by one server process, while the late set
of initialization operations is performed by all of the server processes.
More specifically, at system start-up, a single server process
108(
1)
is instantiated. This process
108(
1), referred to below as the primary
process, is the one that performs the early set of initialization operations. Among
others, one of the early initialization operations performed by the primary process
108(
1) is the creation of the shared file
110. This shared
file
110 is created in a portion of physical storage, and is made a part
of the file system. Once created, the file
110 is memory-mapped to a portion
302 of the virtual memory space of the primary process
108(
1).
Once the file
110 is memory-mapped, it may be accessed by the primary process
108(
1) to read and to write data.
Thereafter, the primary process
108(
1) continues to carry
out the operations comprising the early set of initialization operations. At some
point, the primary process
108(
1) completes performance of the early
set of operations, and when that occurs, the primary process
108(
1)
spawns or "forks off" other server processes
108(
2)-
108(
n).
When a server process
108(
2)-
108(
n) is forked off of
the primary process
108(
1), a copy of the primary process's memory
space
108(
1) is made. This copy is used as the starting point for
the memory spaces of the other server processes
108(
2)-
108(
n).
Because this memory space is already memory-mapped to the shared file
110,
and because it is used as the starting point for all of the memory spaces of the
other server processes
108(
2)-
108(
n), it follows that
the memory spaces of all of the other processes
108(
2)-
108(
n)
are also memory-mapped to the shared file
110. In this manner, all of the
server processes
108 are memory-mapped to the shared file
110 at
initialization time. After the server processes
108(
2)-
108(
n)
are forked off, each of the processes
108 carries out the late set of initialization
operations. Once those operations are performed, the various server processes
108
are ready for regular operation.
During regular operation, the server processes
108 access the shared
file
110 (FIG. 1) to store and to retrieve session information. The manner
in which the processes
108 utilize the shared file
110 is best understood
with reference to an example. Suppose that a request is received from a client
102 to start a new session, and that this request is assigned to server
process
108(
1). Since this is a request to start a new session, server
process
108(
1) will create a new session and an associated new session
ID. To determine which session ID to assign to the new session, the server process
108(
1) consults the index portion
202 of the shared file
110
(FIG.
2), and more specifically, the session ID column
210 of the
index table. Based upon the current session ID values, the server process
108(
1)
creates a new unique session ID, and associates it with the new session. Thereafter,
the new session ID is inserted into the session ID column
210 of a new row
of the index table. In addition, a reference to a free data bucket is inserted
into the data bucket column
212 of that same row (for the sake of example,
it will be assumed that the free data bucket is bucket
206(
1)). The
association between the session ID and the free data bucket
206(
1)
is thus made. Thereafter, bucket
206(
1) will be used to store the
session information for the new session.
A In updating the index portion
202 of the shared file
110, the
server
process
108(
1) takes precautions to ensure that other processes
108
are not also updating the index table at the same time. If simultaneous update
occurs, processing errors may result. To prevent simultaneous update, the server
process
108(
1) obtains a lock on the index portion
202 prior
to any update. In one embodiment, the lock is obtained by requesting and obtaining
a semaphore from the operating system
112. Once the semaphore is obtained,
the server process
108(
1) is free to update the index portion
202.
As soon as updating of the index portion
202 is completed, the server process
108(
1) releases the semaphore, thereby enabling the other processes
108 to update the index portion
202, if so desired. In this manner,
the index portion
202 is updated safely.
Once the index portion
202 is updated, the data bucket
206(
1)
associated with the new session ID is accessed, and the busy flag
208(l)
stored therein is set to indicate that the session associated with the bucket
206(
1)
is currently being serviced. With that done, the server process
108(
1)
proceeds to service the request. In servicing the request, session information
may be generated. When servicing of the request is completed, the server process
108(
1) stores this session information into the data bucket
206(
1).
In addition, the server process
108(
1) resets the busy flag
208(
1)
to indicate that the session is no longer being serviced. Furthermore, the server
process
108(
1) sends the new session ID and a response page to the
client
102 as a response to the request. Once that is done, the request
is fully serviced.
Suppose now that the client
102 sends a second request pertaining
to the same session, and includes in the second request the session ID received
in response to the first request. Suppose, though, that this second request is
assigned to server process
108(
n), not server process
108(
1).
This situation would have posed a problem for the prior art; however, with the
present invention's ability to share session information across multiple processes,
this second request is processed properly, just like any other request. More specifically,
in response to the second request, the server process
108(
n) determines
whether the request pertains to an already existing session. Since the request
includes a session ID, it is clear that it does pertain to an existing session.
That being the case, the server process
108(
n) uses the session ID
to find the associated data bucket in which session information pertaining to this
session is stored. More specifically, the server process
108(
n) compares
the session ID with the session ID's stored in the session ID column
210
of the index table. Unless there is an error, or the ID has expired, a matching
entry will be found. The data bucket reference contained in that matching entry
will lead the server process
108(
n) to the proper data bucket. In
this example, it is data bucket
206(
1).
Once the associated data bucket
206(
1) is determined, it is accessed
by the server process
108(
n). In one embodiment, the server process
108(
n) first checks the busy flag
208(
1) stored in
the bucket
206(
1) to determine whether it has been set. If so, then
it means that that session is currently being serviced by another process
108.
In such a case, the server process
108(
n) waits until the busy flag
208(
1) is reset before processing the second request. This ensures
that a session is serviced by only one process
108 at a time to prevent
potential processing errors. On the other hand, if the busy flag
208(
1)
is not set, then the server process
108(
n) sets the flag
208(
1),
and then proceeds to retrieve the session information from the bucket
206(
1).
This session information is the same information as that stored by the server process
108(l) after servicing the first request. Thus, it contains all of the session
information pertaining to this session. Thereafter, the server process
108(
n)
uses the session information to service the second request. In servicing the second
request, the session information may be modified, and additional session information
may be generated. When the server process
108(
n) completes servicing
of the second request, it stores all of the session information back into the data
bucket
206(
1). In addition, it resets the busy flag
208(
1)
to indicate that the session is no longer being serviced. Furthermore, the server
process
108(
n) sends the session ID and a response page to the client
102 as a response to the second request. Once that is done, the second request
is fully and properly serviced. Note that although the first and second requests
were processed by different server processes
108(
1),
108(
n),
both requests were serviced properly. No session information was lost, and no session
information was corrupted. Therefore, as this discussion shows, the present invention
makes it possible to manage session information safely in a multi-process environment.
Thus far, the invention has been described at a relatively high level. With
reference to the functional block diagram of FIG. 4, which shows one possible embodiment
for the server processes
108 of FIG. 1, the invention will now be described
in greater detail. In the embodiment shown, each server process
108 comprises
a listener
410, a set of name translation functions
412, and a set
of service subsystems
414. The primary function of the listener
410
is to receive a client request, parse the request into its various components (e.g.
method, headers, universal resource identifier (URI), parameters, etc.), and store
the various components into predefined structures. Once the request is parsed,
it is ready for processing by the other components of the server process
108.
In particular, the name translation functions
412 determine, based upon
the URI of the request, which of the service subsystems
414 need to be invoked
in response to the request. In one embodiment, there is a name translation function
associated with each of the subsystems
420,
422,
424 in the
service subsystems
414. These name translation functions are executed in
turn to determine which subsystem
420,
422,
424 needs to be
invoked to process the request. For example, the name translation function associated
with the HTML engine
422 is invoked to determine whether the HTML engine
422 needs to be invoked to respond to the request. If not, then the name
translation function associated with the service engine
420 is invoked to
determine whether the service engine
420 needs to be invoked to respond
to the request. This process of executing the name translation functions
412
continues until it is determined which of the service subsystems
414 needs
to be invoked to process the request. Once the proper subsystem is determined,
processing of the request continues with that subsystem.
As shown in FIG. 4, one of the service subsystems is the service engine
420.
In one embodiment, the service engine
420 coordinates interaction between
the applications
444 and the session manager
434 to manage session
(i.e. state) information for exchanges that span multiple client requests. In carrying
out its coordination function, the service engine
420 performs at least
three major functions. First, it determines based upon the URI of the client request
which application class
442 needs to be invoked to process the client request.
Then, it invokes the proper application class
442 to give rise to an application
instance
444. Thereafter, the service engine
420 invokes the session
manager
434. Once that is done, the application instance
444 and
the session manager
434 interact with each other to access and to update
session information relating to a particular session.
To enable the service engine
420 to determine which application class
442
to invoke in response to a particular URI, each application class
442 is
registered. In one embodiment, this registration takes the form of an entry in
a configuration file. This entry comprises a reference to a particular application
class
442, and a URI associated with that class
442. Given this information,
the service engine
420 can determine, based upon the URI of the request,
which application class
442 to invoke to service the request.
In addition to invoking the application classes
442, the service engine
420 also invokes the session manager
434. In one embodiment, the
service engine
420 invokes the functionality of the session manager
434
via a set of methods implemented by the session manager
434. According to
one embodiment, these methods include: (1) Init; (2) CreateSession; (3) DeleteSession;
(4) GetSession; (5) PutValue; (6) GetValue; (7) Update; and (8) Reaper.
The Init method is called upon initialization of the session manager
434
and is called only once. When invoked, the Init method prepares the session manager
434 for normal operation. The CreateSession method is invoked when a new
session needs to be created. This typically occurs when a client invokes an application
class
442 for the first time. The DeleteSession method is invoked to render
an existing session invalid. This may occur at the end of a transaction or when
a session "times out". The GetSession method is invoked to access an existing session.
This is used to continue an ongoing session. The PutValue method is invoked to
write information into an existing session. This is usually invoked to write additional
state information into an existing or new session. The GetValue method is invoked
to retrieve state information from an existing session. This method makes it possible
to ascertain what has transpired thus far in a particular session. The Update method
is invoked when current processing of a session is completed. It gives the session
manager
434 an opportunity to perform certain functions, such as storing
the session information persistently into the shared file
110, to complete
the servicing of a request. The Reaper method is invoked periodically by an external
mechanism (such as a dedicated thread) to cause the session manager
434
to delete old or invalid sessions. This method causes the session manager
434
to perform "clean up" operations on outdated sessions.
In maintaining state information pertaining to sessions, the session manager
434
uses session objects. More specifically, the session manager
434 instantiates
a session object for each session, and that session object is used as a container
to store session information for that session. These session objects are instantiated
from a session object class,
