There's still questions about whether things should be <CFLOCK>'ed or not. This particular discussion happened on twitter where a developer was concerned that his session would bleed over into another user's session. To be clear, this was a major bug in the server. It happened back in the CF5 days. Suddenly there was a massive shift to get all the developers to cflock all of their session/application code. All of it. If it's not already obvious, there's performance rammifications behind this.

These days, 4, almost 5, versions later, gone are the days where you had to worry about session collision. Note, I'm not saying, don't use cflock. I'm saying, use them for an entirely different reason. Race conditions. If you have a session.user.isloggedIn and that's structure holding a boolean value and it should only ever be either true or false, but the timing of flip between true or false is important then you should be concerned which functions are messing with it. If there's a possibility that anything more than one function is flipping the value from true or false at any given moment, then you have the potential for a race condition.

From Wikipedia:
"A race condition or race hazard is a flaw in an electronic system or process whereby the output or result of the process is unexpectedly and critically dependent on the sequence or timing of other events"

The important part of this quote being: critically dependent on the sequence or timing.

By putting <cflock type="exclusive">, you're forcing other processes that are manipulating that session variable to wait in line via single threading. <cflock type="readonly"> allows mutli-threading reading of the variable so anything can get at it, except when it's busy being exclusive.

Also, cflock isn't exlcusive to sessions / applications. You may run into a process where you need a variable to be watched carefully (the internals of a cfobject as an example). Then, you use exclusive NAMED locks (e.g. <cflock name="somename" type="exclusive">).

As a side note, Application.cfc's onApplicationStart() / OnSessionStart() are already single threaded, you don't need to worry about cflocking. What you do need to worry about is if you have a restart configuration in OnRequestStart or OnRequest that re-initializes application / session vars by calling <cfset onSessionStart()> or <cfset onApplicationStart>, this is not thread safe and subjected to race conditions.

I guess this tip only applies to those of you that haven't fully jumped over to ORM yet and still write your own SQL. One of the habits that I've gotten into seems to have dramatically cut down the amount of SQL errors complaining about commas for me. It's very simple.

Instead of writing insert/update statements like such:

<cfquery name="insert">
INSERT INTO tablefoo(col1,col2)
VALUES(
<cfqueryparam value="#data1#">,
<cfqueryparam value="#data2#">
)
</cfquery>

I write them as:

<cfquery name="insert">
INSERT INTO tablefoo(col1,col2)
VALUES(
<cfqueryparam value="#data1#">
,<cfqueryparam value="#data2#">
)
</cfquery>

Why? It's easier for me to look down the list and scan for missing commas.

Anyway, just a stupid little tip that seems to be working for me. I doubt I'm the first that have done this. ;)

Today is "How I got started in ColdFusion" day, a great idea suggested by Steve Bryant.

Back in the mid 90s, I was working for a Mom & Pop ISP as a "Webmaster." The problem with Mom & Pop ISPs is that sometimes they weren't so reliable in paying. After my 2nd bounced check, I decided that it was time to leave. I came back to the PA area, specifically around Pittsburgh because my older brother was living in the area and he let me crash on the couch while I was looking for a job.

In '97, I landed a job at a place called MetalExchange (later renamed to MetalSite). I was doing Tech Support at first, but being employee number 11 (out of 200 something), you eventually start moving up through the ranks. I got promoted to QA. They sent me to a ColdFusion class so that I would be able to assist better with QA.

A bunch of us went to class and Glenda Vigoreaux was our teacher for the "Fast Track to ColdFusion 4.0" training. The CTO at the time saw that I was picking up CFML faster than some of the other programmers and that was basically because I wasn't struggling with all the HTML tags and such.

A week later, after training, they promoted me to a developer. I started picking up contacts with people at Allaire and hanging out on the forums and learning even more. Two months after that, I was promoted to a manager. I was responsible for getting all the new developers in the door more training (which, we brought Glenda back twice more to Pittsburgh for).

Around 2001 or so, the company started going downhill (dot com bubble popped) and I jumped ship having survived 2 rounds of layoffs. I found a little firm in Pittsburgh that was looking for a ColdFusion developer for a 6 month contract that could possibly lead to long term. I came on as a consultant. 6 months later, I signed on full time.

11 years later, I'm still with the same company. I've worked with a lot of big name clients in the Pittsburgh area.

I've had a lot of great opportunities thanks to my adventures with ColdFusion (Team Macromedia, Going to Japan for my previous job, Meeting awesome people at conferences, etc). The only rough patch when I was really starting to doubt ColdFusion was when ColdFusion MX was released (6.0, 6.01... 6.02 was semi-stable).