Re: referencing #application.applicationname#
The appropriate use of locks can be really important. Here's a case in point that cost me a LOT: I did an application for a client where to save processing time, I put a couple of variables used many times into the application scope. In this case I wasnt allowed to deploy the application to the production server myself, their staff programmer was going to do it. I had to write the code, demonstrate, test it and prove it on a dev server, then give them the code to deploy on production. Nothing too unusual there. Except the person who did the deployment to production didnt listen to what I told him, didn't read my installation notes, and didnt know much about modern ColdFusion. His knowledge was based back in CF5. He looked at my code, scoffed at all my unlocked reads of application variables and corrected it by putting locks around every access of application vars. In this application that was about 50 places in 5 files. For good measure he put locks on every datasource access as well. When 400 users started using this application (it was something they all access many times a day) all these locks brought the entire system to its knees.Instead of doing what normal people would do and calling me to tell me to come and sort out the problem, they decided that my code had brought their system to its knees, they dumped my application and set their staff guy to re-writing what I'd done and told me i wasnt needed any more. If they'd have called me, I'd have been there in 30 minutes, looked at the changes their staff guy had made, fixed them, and it would have been up and rolling inside an hour. Sadly, I wasn't given the opportunity to have a say, or correct what they had already decided was my mistake. My point here is that locks, if used incorrectly, can wreck an application, or as in this case bring an entire server and database to a crawl. Cheers Mike Kear Windsor, NSW, Australia Adobe Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month p.s. when I last heard, they were still putting locks around every application scope and database access, and had decided that ColdFusion ran too slow, so they were re-writing their whole system in dotnet instead. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334216 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
Does this require a lock? I was reading through the CF WACK, and it has an example like so: cflock name=#application.applicationname#_whatever type=exclusive timeout=10 does reading the app scope require a lock? Would I nest two locks? Or is it not required because the application name does not change? Barney's response - specifically his first paragraph - provides a very good answer, but there are some additional details which might be helpful. Prior to CFMX, concurrent access to variables could cause server stability problems, so most developers at the time locked all access to anything in the Server, Application or Session scopes. That legacy remains in a lot of code samples even today - once you learn a habit, it's hard to unlearn. But as Barney said, you don't need to lock access to code unless that code can cause a race condition. If you are going to use locks - presumably because you might have a race condition - you'd need to lock both the reads and the writes that might happen concurrently. So, yes, reading the app scope would likewise require a lock set to TYPE=READONLY. You should NEVER nest locks. Locks, by their very nature, cause bottlenecks, and nested locks can cause unpredictably bad bottlenecks. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsit ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334139 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
Do you remember what chapter that is? I'm 99% sure CFWACK makes it clear that locks aren't necessary for simple reads. I remember writing those updates myself a few revs back but I'd like to confirm the current text is clear. On Sun, May 30, 2010 at 4:29 PM, Matthew P. Smith m...@smithwebdesign.net wrote: Does this require a lock? I was reading through the CF WACK, and it has an example like so: cflock name=#application.applicationname#_whatever type=exclusive timeout=10 does reading the app scope require a lock? Would I nest two locks? Or is it not required because the application name does not change? ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334141 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
Are you and Barney speaking English? I suspect this is just a joke on your part, and I'm not really addressing this response to you specifically. But the reason I'm still on this list is mostly people like Barney and Sean. When I read their posts, I'm likely to learn something I didn't know before. I may not even understand the topic they're discussing at first, but that's how we learn new things. I started programming when most programmers were building desktop applications, and concurrency wasn't usually much of an issue for them. Nowadays, of course, concurrency is an issue for all of us since we build multiuser applications. But a lot of CF programmers, in my experience, aren't prepared to understand or deal with concurrency issues - and I think this explains some of the feeling in the larger world of programming that CF is a toy language. Many CF developers don't understand how databases deal with concurrency, or how concurrency affects their own applications. CF developers very often don't seem to know what's going on in that larger world of programming, and we should. We don't all have to be computer scientists, but we should at least know the basics of our trade. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334142 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: referencing #application.applicationname#
Yes, it was a joke. And while I don't always learn specifics from Barney's or Sean's posts, I almost always find out about topics of which I've never heard. So keep it up Barney/Sean...you guys spur the rest of us onwards. andy -Original Message- From: Dave Watts [mailto:dwa...@figleaf.com] Sent: Monday, May 31, 2010 9:59 AM To: cf-talk Subject: Re: referencing #application.applicationname# Are you and Barney speaking English? I suspect this is just a joke on your part, and I'm not really addressing this response to you specifically. But the reason I'm still on this list is mostly people like Barney and Sean. When I read their posts, I'm likely to learn something I didn't know before. I may not even understand the topic they're discussing at first, but that's how we learn new things. I started programming when most programmers were building desktop applications, and concurrency wasn't usually much of an issue for them. Nowadays, of course, concurrency is an issue for all of us since we build multiuser applications. But a lot of CF programmers, in my experience, aren't prepared to understand or deal with concurrency issues - and I think this explains some of the feeling in the larger world of programming that CF is a toy language. Many CF developers don't understand how databases deal with concurrency, or how concurrency affects their own applications. CF developers very often don't seem to know what's going on in that larger world of programming, and we should. We don't all have to be computer scientists, but we should at least know the basics of our trade. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ http://training.figleaf.com/ Fig Leaf Software is a Veteran-Owned Small Business (VOSB) on GSA Schedule, and provides the highest caliber vendor-authorized instruction at our training centers, online, or onsite. ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334144 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
On Sun, May 30, 2010 at 7:41 PM, andy matthews li...@commadelimited.com wrote: Are you and Barney speaking English? Nanu nanu :) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334146 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
locks aren't necessary for simple reads to prevent memory corruption. They ARE necessary if you have a potential race condition. To put that another way, CF5 and before required locks to prevent memory corruption, but CF6+ does not. However, if you care about your application behaving correctly (not just having non-corrupted memory), then read-only locks are absolutely needed in certain cases. Macromedia rather botched up this message, I think, when the change first happened, because they implied that you no longer had to lock reads. In reality, you only get to avoid the lock when you have a read on a single shared scope variable. If you have multiple reads, you must at least consider whether a lock is required (it should be, but you can sometimes safely skip it). If you have a read and then a write, you MUST lock the read. In this latter case you can do a read-only lock and then escalate to an exclusive for the write if that'll reduce the serialization of concurrent requests, but the read MUST be in a lock. I don't want to be an anal retentive pedant, but this is REALLY important. Doing it wrong will only manifest bugs under weird situations, so the chance of organically identifying and correcting the bug is nearly zero. If you get it wrong, it's going to be a under-load data corruption issue (not memory corruption, mind you, data corruption) in production that tells you you have a bug. cheers, barneyb On Mon, May 31, 2010 at 7:52 AM, Raymond Camden rcam...@gmail.com wrote: Do you remember what chapter that is? I'm 99% sure CFWACK makes it clear that locks aren't necessary for simple reads. I remember writing those updates myself a few revs back but I'd like to confirm the current text is clear. On Sun, May 30, 2010 at 4:29 PM, Matthew P. Smith m...@smithwebdesign.net wrote: Does this require a lock? I was reading through the CF WACK, and it has an example like so: cflock name=#application.applicationname#_whatever type=exclusive timeout=10 does reading the app scope require a lock? Would I nest two locks? Or is it not required because the application name does not change? -- Barney Boisvert bboisv...@gmail.com http://www.barneyb.co ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334148 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
On Mon, May 31, 2010 at 11:56 AM, Barney Boisvert bboisv...@gmail.com wrote: locks aren't necessary for simple reads to prevent memory corruption. They ARE necessary if you have a potential race condition. It's also worth noting that whether you need to lock or not depends on the type of data being shared and the way it is accessed. It's a hard problem to understand. Here's a real world example: FW/1 - my framework - is thread safe under normal operation. onApplicationStart() performs all the basic initialization and any subsequent cache updates are exclusively locked. Reads don't need to be locked because cached data is set once and not subsequently updated (modulo the usual VAR scope issues in user-supplied CFCs, of course). However, when you force the framework to reinitialize in a regular request and you are using a bean factory, it is possible for the bean factory to be removed for a very short period before it is recreated (by user code) and it is possible for another thread to get in and create a component and attempt to autowire it (using said missing bean factory) which leaves the newly created object in a bad state. Possible but not very likely, except under heavy traffic or if you have the framework in reload-on-every-request mode and you have a lot of ajax calls in your pages (generating multiple concurrent requests while the framework is reloading multiple times). I have to figure out a way to reliably execute the code so that scenario goes away - because locking access / updates is going to have a performance impact for the mainstream use case (I actually have a solution in mind which doesn't involve locking because I can rely on how the code executes during a reload even in the present of multiple concurrent requests). then read-only locks are absolutely needed in certain cases. And this is the problem for most CFers: what are those 'certain cases'? If they don't know, they'll tend to lock everywhere and performance will suck and CF will get a black eye for 'performing badly'. It is a hard problem and web developers really *do* need to learn about this stuff... In reality, you only get to avoid the lock when you have a read on a single shared scope variable. (depending on its type and how updates are performed on it) If you have a read and then a write, you MUST lock the read. Not in all cases. If the variable is atomic and it's value can either be safely predicted in a multi-threaded scenario - or it's value doesn't matter (e.g., it's cached data that doesn't have to be 100% up-to-date in real time - rather than a critical accumulator value) - then you still don't need to lock. I don't want to be an anal retentive pedant, but this is REALLY important. We agree there :) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwoo ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334151 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing ##application.applicationname##
Klaatu Verata Nicto ;) larry Are you and Barney speaking English? Nanu nanu :) -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwood ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334155 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
referencing #application.applicationname#
Does this require a lock? I was reading through the CF WACK, and it has an example like so: cflock name=#application.applicationname#_whatever type=exclusive timeout=10 does reading the app scope require a lock? Would I nest two locks? Or is it not required because the application name does not change? ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334128 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
CFLOCK is only required to serialize access to prevent race conditions. For immutable state, no race conditions can arise, so locking is unneeded. Since application.applicationname is immutable, you don't need to lock access to it. In a more general sense, anything that is only accessed in a read-only and side effect-free fashion doesn't need to be locked. This is the reason that functional languages are so supremely suited to highly concurrent applications. With immutable state and side effect-free operations, the issue of concurrency basically vanishes from the programmer's mind. This purity of environment only works completely in academia, but a very close approximation can be created that is useful for real-world problems. Clojure (a JVM-based Lisp dialect) is an example of this, leveraging Actors to deal with concurrent modification problems without foisting the hassle of locking on the developer. cheers, barneyb On Sun, May 30, 2010 at 2:29 PM, Matthew P. Smith m...@smithwebdesign.net wrote: Does this require a lock? I was reading through the CF WACK, and it has an example like so: cflock name=#application.applicationname#_whatever type=exclusive timeout=10 does reading the app scope require a lock? Would I nest two locks? Or is it not required because the application name does not change? ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334129 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: referencing #application.applicationname#
On Sun, May 30, 2010 at 2:39 PM, Barney Boisvert bboisv...@gmail.com wrote: This purity of environment only works completely in academia, but a very close approximation can be created that is useful for real-world problems. Clojure (a JVM-based Lisp dialect) is an example of this, leveraging Actors to deal with concurrent modification problems without foisting the hassle of locking on the developer. Clojure also implements STM natively (Software Transactional Memory - a approach which is gaining popularity lately and attempts to apply database-style transactions to memory access in applications). Scala is probably more approachable for folks familiar with Java and it too has a concurrency model based on Actors, as well as an STM implementation. Groovy also has an Actor implementation called GPars. The Groovy community is also looking at STM. Scala Actors: http://www.scala-lang.org/node/242 - Scala Actors STM: http://en.wikipedia.org/wiki/Software_transactional_memory STM in Scala: http://www.codecommit.com/blog/scala/software-transactional-memory-in-scala Groovy Actors in GPars: http://gpars.codehaus.org/Actor -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ If you're not annoying somebody, you're not really alive. -- Margaret Atwoo ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334130 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: referencing #application.applicationname#
Are you and Barney speaking English? -Original Message- From: Barney Boisvert [mailto:bboisv...@gmail.com] Sent: Sunday, May 30, 2010 4:39 PM To: cf-talk Subject: Re: referencing #application.applicationname# CFLOCK is only required to serialize access to prevent race conditions. For immutable state, no race conditions can arise, so locking is unneeded. Since application.applicationname is immutable, you don't need to lock access to it. In a more general sense, anything that is only accessed in a read-only and side effect-free fashion doesn't need to be locked. This is the reason that functional languages are so supremely suited to highly concurrent applications. With immutable state and side effect-free operations, the issue of concurrency basically vanishes from the programmer's mind. This purity of environment only works completely in academia, but a very close approximation can be created that is useful for real-world problems. Clojure (a JVM-based Lisp dialect) is an example of this, leveraging Actors to deal with concurrent modification problems without foisting the hassle of locking on the developer. cheers, barneyb On Sun, May 30, 2010 at 2:29 PM, Matthew P. Smith m...@smithwebdesign.net wrote: Does this require a lock? I was reading through the CF WACK, and it has an example like so: cflock name=#application.applicationname#_whatever type=exclusive timeout=10 does reading the app scope require a lock? Would I nest two locks? Or is it not required because the application name does not change? ~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology-Michael-Dinowitz/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:334133 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
