PART II
Chapter 6: Networking Considerations 255
- Two users visit an e-commerce page and see 10 units available.
- User A makes request 1 for 10 units, which goes out first.
- User B makes request 2, which goes out shortly after and wants 3 units.
- Request 2 arrives first despite being issued later and takes three units.
- Request 1 is denied despite the user seeing that units were available when they
ordered.
Certainly there might be some user dissatisfaction, but there is nothing wrong with this
scenario programmatically speaking. You might even think about the idea that it is possible
that both saw the 10 units available so that if request 2 gets there and it is sold out then they
are unhappy. However, from the simple example, you can see that in some sense there was
a race for resources and who arrived first was variable. However, it is possible to create
something a bit more problematic called a race condition using the same basic scenario.
Simply put, a race condition is a flaw in application design whereby the output of a
process is critically dependent on the sequence or timing of other events. The general sense
of the term is that two individual events or even requests are racing each other to influence
the output first.
Race conditions usually aren’t seen in Web applications, as they are most often caused
by multiple threads, which are not common in the traditional batch-style Web application.
Typically, a single client (the browser) is only connected to the server with one thread of
execution at a time. With Ajax, this is not the case. It is now possible to have a single client
with multiple connections to the server. The local variables inside of the page are safe;
however, session variables stored on the server may not be.
As an example of a race condition, imagine a case where there are two pages that both
set the same session variable. If they are both sent off at the same time, you really have no
idea what the session variable will be. It will depend on which gets there last, hence, the
“race.” Consider in this chapter where, so often, just because one request is sent before
another, there is no guarantee that it will arrive at the server first. Thus, while you can think
that you are setting the session variable to the first value and then the second, it might
actually be the reverse.
Fortunately, many server-side environments such as PHP have locks built into their
sessions by default. So if you are using the basic PHP sessions, these problems will not be
encountered. Built-in session locking can be seen in action at http://ajaxref.com/ch6/race
.html. In this example, two requests are sent out that will set the session variable. The first
sets it to value1 and the second sets it to value2. Because it is expected that the second
request will happen last, it is easy to conclude that the session variable should be value2 in
the end. To throw a twist on the example, a delay was placed on the first request so that, in
theory, the second request would finish first. However, thanks to the PHP session locking,
request 2 does not go through until request 1 completes and all is fine.
While built-in sessioning should work, there may be situations where developers may
build their own session handling system. If this is the case, extreme caution should be
employed. As an example, (http://ajaxref.com/ch6/racesession.html) is identical to the first
except for how the session is handled. A proper lock on the session value is not employed.
Given the delay on first request, the second request completes first, and without the locks,
the session variable winds up being ultimately set to the value of the first request which isn’t
what was desired. Both examples are shown together in Figure 6-15.