>> -----Original Message-----
>> From: S. Isaac Dealey [mailto:info@;turnkey.to]
>> Sent: Friday, November 01, 2002 1:32 PM
>> To: CF-Talk
>> Subject: RE: Understanding Locking In CFMX
>>
>>
>> I think that what ends up being the case is that <cflock> is
>> actually a good
>> powerful tool to do something important that most people ignore or would
>> rather ignore. So often people wind up saying "oh you don't have
>> to lock in
>> MX" because that's the way they'd _like_ it to be, but the same problems
>> exist in PHP and ASP.
> I don't really care if I have to lock in CFMX, I just wanted a better
> explanation, which Sean provided. I think his extensive post cleared up a
> lot of things in that area.
I was just explaining why a lot of the talk about locking in MX is confusing
or contradictory -- why you keep hearing people say "you don't need to" and
then other people saying "no, you still do".
>> I don't know how ASP and PHP programmers handle the issue of race
>> conditions
>> -- with PHP because I've not really worked with it. With ASP
>> because in the
>> year that I did ASP programming I never heard it mentioned. Does that
>> mean
>> it wasn't an issue? Probably not. In the year that I worked with ASP
>> there
>> were a lot of things I never did -- I never implemented COM for isntance.
>> Does that mean that COM is a non-entity? Nope.
> Mike Townend pointed out to me that you do have to lock in ASP. Locking
> the
> Application scope is done with: Application.lock. As far as I can tell
> from
> my reference books, you only need to lock writes. But as Sean pointed out
> in his reply, there are certain situations which require a little more
> thought than others in regards to locking. Perhaps this is the case with
> ASP as well, I don't know.
I would expect that to be the case.
>> 1) If ASP or PHP don't have this problem, then they must be
>> single-threading
>> sessions, which is going to slow down page requests, especially
>> under heavy
>> load, which means that CF is one up on them because CF allows you
>> to turn on
>> or off the single-threading of sessions and either not worry
>> about locking,
>> or get more speed, dependant on your needs.
> From what I've seen, PHP and ASP scored higher than the previous versions
> of
> CF in regards to pages processed per second, so if they were indeed single
> threading, which I doubt they were, it would be sad if CF didn't have a
> higher page per second score in that case.
Yep. :) Though I think CF has had more features than PHP and ASP in previous
version as well...
As an asside --
I don't personally remember ASP being faster -- I actually remember it being
slower during the year I did ASP work, though that was about 4 years ago.
One of the reasons for ASP's being slower ( and this is only on an
application per application basis ) was ASP's inability to dynamically
include files. The reason for this is that when you wanted to separate code
out into modular includes to make things easier to read and/or to limit the
size of any given template, you'd wind up using conditional logic in ASP
that would obscure the content of a given file, but because the includes are
SSI's and the SSI's have to be processed prior to the conditional logic,
even when you turned an include file off so to speak, the server still had
to work on that file.
In CF you can be assured that only one of the files in this switch statement
gets any processing time.
<cfswitch expression="#fuseaction#">
<cfcase value="..."><cfinclude></cfcase>
<cfcase value="..."><cfinclude></cfcase>
<cfdefaultcase><cfinclude></cfdefaultcase>
</cfscriwtch>
but in ASP, one of the most common practices is to use something like this
for both the header and the footer on the page to determine what should be
displayed. ( forgive me, I forget the VB syntax )
<% select case (pagestyle) {
case 1: { %>
<!--#include relative=pageheader_1.asp --><% }
case 2: { %>
<!--#include relative=pageheader_2.asp --><% }
default: { %>
<!--#include relative=pageheader_0.asp --><% }
<% } %>
With the end result being that ( asside from the fact that the syntax is
nothing but ass because you're breaking the script flow for each case
statement and in all honesty, the includes aren't actually part of the
script because they're not processed by the ASP engine ) the webserver has
to process the SSI and include the file 3 times at both the top and bottom
of the page which at least in our case created quite a bit of drag on the
server. My understanding at the time was that this was par for the course
for ASP and helped to make equivalent CF pages load much faster. Probably it
would have been better to place all the header and footer info for each page
style in a db record and just output it as a flat file, but I don't remember
ASP programmers really doing that by and large.
I'm not sure if this is still true in ASP.NET and C# ... I suspect it's not,
but I haven't really delved into .NET at this point.
S. Isaac Dealey
Certified Advanced ColdFusion 5 Developer
www.turnkey.to
954-776-0046
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
