← Back to branch summary

~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to src/README

  • Committer: mattgiuca
  • Date: 2007-12-12 04:22:22 UTC
  • Revision ID: svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:trunk:41
Moved Tom's notes from README (application doc) to notes/session.txt
(development doc).

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/README
71
71
* /dispatch - Handler module for the top-level dispatch.
72
72
* /media - Contains files directly served by Apache (see above).
73
73
* /conf - Administrator configuration files (see /conf/README).
74
 
 
75
 
Notes on mod_python.Session
76
 
---------------------------
77
 
 
78
 
``mod_python`` provides some automagic for cookie based sessions. It
79
 
carefully separates most of the session logic from how the session is
80
 
stored. The base class `BaseSession` contains most of the logic, and
81
 
``mod_python`` itself has three derived classes for storing session
82
 
objects in-memory, dbm, and on the filesystem. In each case, the
83
 
implementations use apache's locking mechanism to serialize updates to
84
 
the store of cookies. This mechanism takes care of mutual exclusion
85
 
between the multiple processes of an apache instance, but does not
86
 
provide any facility to provide any kind locking for multiple servers
87
 
sharing the filesystem for file bases session storage.  There is code
88
 
for storing sessions in MySQL (and SQLLite) floating round on the net,
89
 
though none has made it in to any distributions. This code uses the
90
 
underlying database to take care of the locking.
91
 
 
92
 
In the case of IVLE, we wish to be able to share the session objects not
93
 
merely between the separate processes of an apache instance, but between
94
 
the multiple servers in a load balancing cluster.  There are three high
95
 
level strategies we could use to deal with this:
96
 
 
97
 
1. Use a static load balancing strategy such as hashing the client's IP
98
 
   address to determine which node in the cluster should serve the
99
 
   request.
100
 
 
101
 
2. Use a SQL backend to store sessions, or create a filesystem based
102
 
   storage mechanism that does the necessary locking.
103
 
 
104
 
3. Work around the problem by using session objects in a way that avoids
105
 
   the locking problems.
106
 
 
107
 
Strategy 1 has the advantage that we could use in-memory or dbm session
108
 
storage without having to worry about race conditions between servers.
109
 
On the other hand, it can run into serious problems if the distribution
110
 
of IP addresses is such that load is not balanced. This can be the case
111
 
if an ISP uses NAT firewalling (some do!), since all the requests from
112
 
that ISP will aparently be coming from a single IP address and will therefore
113
 
be routed to the same node in the cluster. As well as the potential for
114
 
failing to balance the load, such a scheme, if it works routes an equal
115
 
proportion of requests to each node in the cluster. At times when overall
116
 
load is light, this may mean that we lose the opportunity to put nodes into
117
 
a powersaving mode, when they are superfluous.
118
 
 
119
 
Strategy 2, while having the advantage of avoiding race conditions, is likely
120
 
to be expensive. The use of a SQL backend is likely to be quite slow, and the
121
 
SQL backend itself will be subject to significant load (i.e. at least one op
122
 
per request). A filesystem based solution is likely to be quite slow too.
123
 
It has to work on a shared filesystem, for which locking is a general issue
124
 
(generally, you end up using `mkdir` as the mechanism for creating a lock).
125
 
If we want mutable session information, then we will *have* to do something in
126
 
this vein.
127
 
 
128
 
Strategy 3 is fragile because we need to be careful about how we use
129
 
session objects, but if the constraints are simple enough to be practicle
130
 
then avoiding the locking issue is highly desirable. A simple constraint
131
 
that may be workable is to require that once created, a session object is
132
 
treated as read-only until it is deleted. It is possible (though unlikely)
133
 
we could create session objects that immediately become orphaned, but we
134
 
will not ever create a situation in which the application does anything bad.
135
 
If we can make strategy 3 work, then it is easily the best strategy to use.
136
 
 
137
 
The main use for session objects in IVLE will be to *cache* authentication and
138
 
authorization information. This means that when a user logs in, we authenticate
139
 
(the authentication mechanism is not important to our current discussion),
140
 
then retrieve the authorization information for that user, and store it in
141
 
the session object. For each page access until the user logs out, we can then
142
 
use the information from the session object.