> -----Original Message-----
> From: Ben Rogers [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 31, 2004 5:43 PM
> To: CF-Talk
> Subject: RE: Well - I feel like an idiot.
>
> > Which is exactly why you have to be consistent with locking. ;^)
>
> I don't see how consistency directly relates to what I was talking about.
> Modular code generally knows very little about its context: that's the
> whole
> point. You can be entirely consistent and still end up with deadlocks if
> one
> piece of code isn't aware of what's going on around it.
True - but that mean you shouldn't be consistent with your code. At the
very least any extensions that you or your team's written would be unable to
cause such deadlocks.
> > Generally nesting concerns would only happen with scope level locking or
> > site-wide name-level locks.
>
> The names used in "name level locks" are completely arbitrary. What
> happens
> when you call a third party CFC that just happens to use the same name
> that
> you use? Better yet, what happens when your cfc, which locks the session
> scope, accesses a singleton registry which locks the application scope?
Although name-level locking is arbitrary it's not at all random. Steps can
be taken to minimize name conflicts (and if there are name conflicts you're
most likely going to have more issues than deadlocks).
For example in my persistent CFCs I use UUIDs as the lock names.
Furthermore in CFMX I don't personally use scope locking at all - that
eliminates most of the causes of contention that we're talking about.
As for a session lock being in place at the same time as an application lock
- so what?
You can only get a deadlock in CF if those locks are nested in BOTH places.
The CFC in question would have to lock the application then session (or vice
versa) and the singleton would have to do the reverse.
As far as I can see that's the only way to get a deadlock in that case.
> > In those cases, despite the encapsulation of
> > extensions you'll need to know something about the application
> > architecture to create them in first place (I think).
>
> You're assuming you have access to and an intimate knowledge of all the
> code
> in question. I used a third party CFC in a recent project. It's encrypted,
> so I have no idea what locks it might create, what scope they are or what
> it
> names them, etc. We used the Component Kit in another project. That stores
> quite a bit of information in the server scope of all places. How did that
> information get there?
Then those are issues with your application. Personally I would ask the
developer of those third party tools to document the locking strategy of the
extension.
For what it's worth I don't think that any CFMX extension should EVER scope
lock exactly for the reasons that you mention. Only name locks should be
used and then steps should be taken to prevent name contention.
This isn't too dissimilar to the issues in the Java world with distributing
packages. The whole "com.mysite.packagename" convention was promoted to
prevent this kind of name contention.
I think the same kind of methodology could be adapted to prevent lock name
contention as well.
> > True - but that would be a failure of design, not of locking. If your
> > template is doing something outside of locks that would affect code
> inside
> > of locks like that I would think you'd need to reevaluate how you're
> doing
> > things.
>
> All failures are a failure of design. :) The point I was trying to make is
> that you have to know a good deal about locking and how your code will be
To true. I stand corrected. ;^)
> This is clearly something we disagree on. I'm sure I'm biased because I've
> seen far more deadlock issues than race conditions.
I might just be the kind of code we see. I tend to see a lot of racing due
to bad UI design (don't get me started on THAT however). Framesets, popup
windows, poor design leading to multiple windows, etc.
A lot of cases are just potential race conditions - the clichéd example is
the single shopping cart linked to multiple windows. I don't honestly think
I've ever seen a real problem related to that, but that's the example
everybody quotes. ;^)
> If the novice is locking everything, then deadlocks are sure to ensue.
> ColdFusion does nothing to prevent the loss of data integrity in a
> deadlock
> situation.
I'm not sure about that (which means, of course, that I could be wrong).
Again - you need nested locks and an inconsistent nesting in multiple
templates.
I rarely see nested locks at all, much less in novice code. Since CFMX was
released I can't remember a case where I've ever needed to nest locks.
In previous versions the classic issues was always the
application-then-session nesting. This nearly ALWAYS showed up due to bad
code like this:
<cflock scope="Application" ...>
<cflock scope="session" ...>
<cfquery datasource="#Application.myDSN#"
password="#session.password#" ...>
</cfquery>
</cflock>
</cflock>
Of course even in earlier versions this is just plain bad code.
But in MX I just don't see nested locks much at all (I can't remember the
last time I've seen any). If I did (and maybe you do - find that guy and
slap him) I'd probably be agreeing with you completely. ;^)
> I actually had to write my own locking routines in ASP a couple of years
> ago. ASP lacks anything analogous to the cflock tag. To make a long story
> short, I discovered the hard way that locking was a far more intricate and
> delicate process than I had thought. I came back to ColdFusion with a new
> found respect for locking issues.
I've done the same thing in JavaScript (and have to do more of it on a
current project)... it's not very pretty.
I've had more than a few conversations with member of the CF dev team about
locking - they always get that "why did you bring up my dead dog" look then
immediately order another round. ;^)
Jim Davis
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net
http://www.cfhosting.net
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189092
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
