RE: CFLOCK Cached Query

2000-10-02 Thread Dave Watts

 Should I CFLOCK the following query?
 
 CFQUERY NAME="Request.GetListings" DATASOURCE="#request.DSN#" 
 USERNAME="#request.USER#" PASSWORD="#request.PASS#"  
 cachedwithin="#createtimespan(0,0,15,0)#"
 SELECT ID,org_name,contact,city,website_bt,email_bt,classified_bt,
 fax_bt,TList
 FROM Orgs (nolock)
 WHERE Class = #VAL(request.hdg_id)#
 CFIF "#CLIENT.CITY#" IS NOT "All Cities" AND City = 
 '#CLIENT.CITY#'/CFIF
 ORDER BY org_name
 /CFQUERY
 
 For different values of request.hdg_id or CLIENT.CITY, CF 
 will cache the correct dataset for NEXT/PREVIOUS display of 
 results on a page (since CF caches reference the SQL too, and 
 not just the cfquery name). There are potentially many DIFFERENT 
 datasets, ALL titled Request.GetListings (in the CF template, that 
 is). For example, CF will cache one dataset where CLIENT.CITY is 
 New York, and another dataset where CLIENT.CITY is Chicago, 
 and they apparently happily co-exist.
 
 But what happens if we followed Allaire's best practices (in 
 CF4.5 syntax):
 
 cflock scope="application" timeout="2" type="exclusive"
  cfset application.GetListings = Request.GetListings
 /cflock
 
 Would the potentially several queries/datasets all named 
 Request.GetListings (in the CF template) be kept distinct 
 when they are named application.GetListings?

First, you shouldn't CFLOCK the query. All CFLOCK does is limit who can
execute the code at a given time. You don't have any memory variables within
the query that need to be protected from concurrent accesses, so you don't
need to use CFLOCK.

Second, cached queries aren't stored the same way as persistent memory
variables are stored. That is, they're not simply identified by name. You're
only going to have one variable called Request.GetListings (or
Application.GetListings) and that variable will contain whatever you put
into it. Query caching only comes into play when you execute a CFQUERY tag
with a caching attribute - CF looks to see whether there's a matching
recordset already cached.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
--
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.



RE: CFLOCK Cached Query

2000-10-02 Thread paul smith

So are you saying we don't need to follow Allaire's Best Practices 
recommendation?  (This is where the cflock example below came from.)

Or, is your statement "First, you..." referring to something else?

best,  paul

At 12:04 PM 10/2/00 -0400, you wrote:

  cflock scope="application" timeout="2" type="exclusive"
   cfset application.GetListings = Request.GetListings
  /cflock

First, you shouldn't CFLOCK the query. All CFLOCK does is limit who can
execute the code at a given time. You don't have any memory variables within
the query that need to be protected from concurrent accesses, so you don't
need to use CFLOCK.

--
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.



RE: CFLOCK Cached Query

2000-10-02 Thread Dave Watts

   cflock scope="application" timeout="2" type="exclusive"
cfset application.GetListings = Request.GetListings
   /cflock
 
  First, you shouldn't CFLOCK the query. All CFLOCK does is 
  limit who can execute the code at a given time. You don't 
  have any memory variables within the query that need to be 
  protected from concurrent accesses, so you don't need to use 
  CFLOCK.
...
 So are you saying we don't need to follow Allaire's Best Practices 
 recommendation?  (This is where the cflock example below came from.)
 
 Or, is your statement "First, you..." referring to something else?

I was saying that you shouldn't place the CFQUERY tag within a CFLOCK, which
was your original question, as I understood it:

 Should I CFLOCK the following query?
 
 CFQUERY NAME="Request.GetListings" DATASOURCE="#request.DSN#" 
 USERNAME="#request.USER#" PASSWORD="#request.PASS#"  
 cachedwithin="#createtimespan(0,0,15,0)#"
 SELECT ID,org_name,contact,city,website_bt,email_bt,classified_bt,
 fax_bt,TList
 FROM Orgs (nolock)
 WHERE Class = #VAL(request.hdg_id)#
 CFIF "#CLIENT.CITY#" IS NOT "All Cities" AND City = 
 '#CLIENT.CITY#'/CFIF
 ORDER BY org_name
 /CFQUERY

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
--
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.



RE: CFLOCK Cached Query

2000-10-02 Thread Dave Watts

 The question I have is whether there's any advantage in 
 scoping a Query cached in a CFQUERY tag as Application.GetListings 
 contrasted with scoping it as Request.GetListings.

I would argue that there isn't any advantage, and should be avoided. When
you do this, you're storing the data in two places: the Application scoped
variable, and the query caching memory. If I were to read the code later,
I'd be confused about which set of data you really wanted to use.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444
--
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.



RE: CFLOCK Cached Query

2000-10-02 Thread paul smith

Thank you, Dave.

This confirms my inclination to use Request-scope
for cached queries.

But I didn't realize an Application-scope cached
query would store two sets of data.

best,  paul

At 03:29 PM 10/2/00 -0400, you wrote:
  The question I have is whether there's any advantage in
  scoping a Query cached in a CFQUERY tag as Application.GetListings
  contrasted with scoping it as Request.GetListings.

I would argue that there isn't any advantage, and should be avoided. When
you do this, you're storing the data in two places: the Application scoped
variable, and the query caching memory. If I were to read the code later,
I'd be confused about which set of data you really wanted to use.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444

--
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
To Unsubscribe visit 
http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk or send a 
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.