> conditions. So tell me, what would you not lock?
Well, not to butt in between you and Sam, but in my experience, most of the
memory variables within an application are unlikely to encounter integrity
issues caused by concurrency (which is all that a race condition is,
really), or if they are, you might not even care about their integrity in
the first place.
For example, it's common to load lots of stuff into the Application scope
for the application as a whole when the application is first run, and
perhaps to load each Session in a similar manner. In either case, race
conditions are unlikely, and if there were a race condition, it would be
unlikely to matter, since this data is essentially just being cached. So,
for those things, locking strikes me as being largely unnecessary.
In addition, you might have variables which just aren't that important. For
example, in the official Macromedia courseware, race conditions are
discussed and an example is provided. That example uses a variable to store
the number of users who have logged into the application. But in real life,
do you really care so much whether a user thinks he's the 53rd user or the
54th?
Finally, rather than recommending a blanket use of locking on all memory
variables rather than just identifying race conditions that you actually
care about, I'd recommend learning about concurrency and synchronization
issues - it's part of the necessary set of knowledge for writing multi-user
applications. On the other hand, if you think you might ever deploy your
application on CF 5 or earlier, it might make sense to just lock everything
anyway.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
