Macromedia Coldfusion MX 7 Web Application Construction Kit
| Like application variables, session variables are kept in the server's RAM. This means that the same types of race-condition problems can occur if session variables are being read and accessed by two different page requests at the same time. (See the section "Using Locks to Protect Against Race Conditions" in Chapter 19.) NOTE If you haven't yet read "Preventing Memory Corruption with Locking" in Chapter 19, please take a look at that section before you continue. Sessions and the <cflock> Tag
Just as it's possible to run into race conditions with application variables, it's also possible for race conditions to crop up when using session variables. In general, it's much less likely that race conditions will occur at the session level than at the application level, as there is usually only one page request coming from each session at any given time. Even though it's unlikely in the grand scheme of things, it still is quite possible that more than one request could be processed from a session at the same time. Here are some examples:
In other words, although race conditions are probably less likely to occur with session variables than they are with application variables, it is still possible to encounter them. Therefore, if the nature of your session variables is such that concurrent access would be a bad thing, you need to use the <cflock> tag. In general, you will use <cflock> just as it was shown in Chapter 19, except you use scope="Session" instead of scope="Application". NOTE Locks of SCOPE="Session" will affect only those locks that have been issued to the same session, which is of course what you want. In plain English, a <cflock> with scope="Session" means "don't let other page requests from this session interfere with the code in this block."
Exclusive vs. Read-Only Locks
In Chapter 19, you learned that there are two types of locks: exclusive and read-only. The main reason to use a read-only lock is to reduce the amount of time your application pages need to sit around waiting for locks to be released and granted. You should use the same basic strategy with session variables. That is, use exclusive locks when making changes, and use read-only locks when just retrieving or outputting the value of a session variable. Since it is less likely for you to get concurrent page requests at the session level than at the application level, using both types of locks is less likely to make a huge difference in overall system performance. But it's still the best practice, since it guarantees that you won't encounter race conditions in your code. Scoped vs. Named Locks
In Chapter 19, you also learned that you can use scope or name to identify a lock. The main purpose for using name is to be able to lock with more precision, so that one widget's locks don't affect another's. Because concurrent page accesses are relatively unlikely to occur at the session level, you probably don't need to worry about getting so specific. Therefore, locking monolithically at the session level is probably sufficient. The only likely scenario where you would benefit from using named locks around session variables would be a frameset page that loaded three or four individual frame pages, all of which need to change and access different session variables. In such a situation, you could make your locks finely grained by creating names for the different "widgets" that store information at the session level. Remember that lock names are considered globally, across the whole server, so you will need to make sure that the lock names include something that uniquely identifies the session. The best way to do this is to use the automatic #SESSION.sessionID# variable as a part of the lock name. For instance, a lock like the following might be used around reads or writes to shopping cart information being maintained at the session level: <cflock name="OrangeWhipShoppingCart#SESSION.SessionID#" type="Exclusive" timeout="10">
|