> Do I have to make all references to Session variables such as session.id
> within a CFLOCK? Does this include references made using them as form and
> URL variables (is this different depending upon wether the server is 4 or
> 4.5)??

CF 4.5 allows you to use a SCOPE attribute on your CFLOCK calls. I believe
this means that you can give your locks arbitrary names (such as "session",
"application", etc) because the SCOPE attribute handles locking the
appropriate data. Above and beyond that I can't tell you much about 4.5 (I
still use 4.01).

CF 4.01 does not support the SCOPE attribute, so you must ensure that each
lock has a name that will block access to the affected scopes
(#cfid##cftoken#, #application.applicationName#, etc).  The only time that
you should not lock an access to these variables is when they are used as
the name of the lock.  The explanation I received was that the CFID and
CFTOKEN and Application Name do not change, therefore there is no danger of
simultaneous reads and writes (the situation that CFLOCK prevents).

> In my Application.cfm page I have something like:
<snip>
> Is this appropriate use of CFLock? (particularly is it ok to use it around
> CFScript?).

As far as I know you can lock blocks of CFSCRIPT code.  In the

> As I am setting my DSN here for use with every query and
> referencing it repeatedly should I put a readonly CFLock around my queries
> even though Application.DSN never changes?

Actually, you should use an EXCLUSIVE lock around your code.  The only time
that code will run is if the application vars do NOT already exist.  In that
case your code will be writing to the shared scope, which means you need the
exclusive lock.

> Would this work with all session and app variables removing the need for
> repeated use of CFLock - e.g setting CFID to a locl var?

Yes, but it may not be worth it.  Multiple readonly locks can access the
shared scopes at the same time, so you may be better off just using the
locks in your code.  The only time that your performance will be affected is
if the shared data is being written to at the same time you attempt to use
it in your code because the lock will prevent your code from running until
the write has completed.

Note that setting local copies of data in the shared scopes will be affected
by this situation as well.

> I'm working on an online store and would like to avoid having to re-query
> for the category names on every page. So if I put this in application.cfm:
>
> <cfif NOT IsDefined("SESSION.CatQuery")>
>          <cflock name="#SESSION.SessionID#" timeout="30">
>                 <cfquery name="SESSION.CatQuery" datasource="#dsn#">
>                          SQL..
>                 </cfquery>
>          </cflock>
> </cfif>

Put the CFLOCK block first.  Calling IsDefined() on data in the shared
scopes is similar to reading the data, which means that the access to the
shared scope needs to be locked.

> Or, it would seem even better to chang all the above session variables to
> applcation variables so the first time they visit the page it doesn't even
> need to run the query then. Then when the DB is updated I could set
another
> variable to indicate that and ensure the query is rerun. (if that makes
> sense) Is that a reasonable thing to do?

If the query is identical for all users then save it in an Application
param.  Otherwise each user will have their own copy of the query in memory,
which could very quickly use up RAM better suited for other tasks.  By
saving the data as an Application param it is only stored in memory once and
everyone can access it.  Also, it makes updating the query easier.

However, if the query results are dependant upon user specific data (CustID,
last time the user was at the store, etc, etc) then you need to use the
Session scope.

Regards,
Seth Petry-Johnson
Argo Enterprise and Associates

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

Reply via email to