CFMBB and Locking

Over the years, I've rarely used cflock for anything.  I still don't fully understand when I should use it. Anyway, I'm concerned about scaling CFMBB... lots of application scoped stuff. For example, there are many places where I do this:        <cfset application.forum.updateForumData()> Application.forum is an instance of forum.cfc ... all the updateForumData() does is run a bunch of queries to make sure the denormalized columns in the forums table (msgcount and lastpost) and in the threads table (lastpost) are up to date.  This method is called each time a message or topic is posted or deleted, and each time a forum or conference is created or deleted. And everywhere I run it, I do this immediately after:        <cfset application.qryForums = application.forum.getForums()>        <cfset application.qryThreads = application.thread.getThreads()> This seems like a place where I might need locking ... but I'm really not sure =) In a very busy environment, this code could run a lot... imagine thousands of active users on a baseball team web site during the world series.. all posting new resposnes to the "official game thread"... where you might get 2000 responses or more during a 3 hour game. And yet your list of threads might get viewed 100 times per second during that time (which is why I'm putting the data - a relatively small amount of data.. just list of forums and list of threads) into the application scope. Comments? -- Rick Root Check out CFMBB, BlogCFM, ImageCFC, ImapCFC, CFFM, and more at www.opensourcecf.com

It sounds like a named, exclusive lock around this would be a good idea, otherwise you will risk inconsistent data coming from multiple requests. ----- Excess quoted text cut - see Original Post for more -----

This is the very definition of a race condition, and will require a lock to ensure data consistency. ----- Excess quoted text cut - see Original Post for more -----

It is a potential race condition, but that doesn't automatically mean that a lock is needed. The data being updated is a list of forums and threads. It may be the case that it doesn't need to accurate to the millisecond. If I create a new thread and someone has a page view at the exact time I do the update, they might miss it, but they will see it on their next page view. A named exclusive lock would make sure that my request doesn't go through until my update is done, but the additional overhead might not be needed in this use case. I think that the worst situation would be a delete of a thread or forum and someone clicks on the link to the item that is in the process of being deleted. But that should just be a situation you'd want to catch anyway. I'm a fan of locking anyway, so I would advocate for an exclusive named lock, but the best answer in this case is probably to try it with the locks, do some load testing, and find out what the overhead is. Then talk to the user base and see what the consensus is on whether the overhead is worth it. Judah Brian Kotek wrote: ----- Excess quoted text cut - see Original Post for more -----

----- Excess quoted text cut - see Original Post for more ----- The answer is, it depends! As James and Brian point out, this is a race condition. The question you need to ask, though, is does this race condition matter? If two requests run this code at nearly the same time, can the second request cause a logical error in the first request? Many race conditions can be safely ignored, since they don't cause logical errors that have any significance. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information!

Rick - its funny - I'm currently making similar changes to Galleon for v2. I have the same feelings as Judah. If I don't lock, it is possible that thread B, which was actually done 1 ms after thread A, may get marked as the "newest" thread - but I figure it just doesn't really matter. ----- Excess quoted text cut - see Original Post for more ----- -- =========================================================================== Raymond Camden, Camden Media Email    : ray@camdenfamily.com Blog      : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org

> Rick - its funny - I'm currently making similar changes to Galleon for > v2. I have the same feelings as Judah. If I don't lock, it is possible > that thread B, which was actually done 1 ms after thread A, may get > marked as the "newest" thread - but I figure it just doesn't really > matter. I feel the same way, and I guess this proves one of the points of a discussion we had a few weeks ago on this list... This is a case where data is worth updating, but it's not necessarily worth locking =) Rick