wouldn't having a write lock nested within a read lock
cause an infinite hold while the write lock waits for
the read lock to end. Is the cf locking "smart" about
two locks in the same session? even still if you had
two sessions at the beginning of the nested write lock
(inside the read lock) they would each wait infinitely
for each other. In the case of variables that need to
be set.. you'd keep building up waiting sessions too..
sounds quite nasty.
The dilemma arose from using a read lock around the
main switch in my root directory index.cfm and a write
lock around the setting of the application variables
in my app_globals. But I've got qry_ files -- which I
very much enjoy calling from my indexes -- that cache
queries in the application scope and would therefore
need to be write locked.
The solutions appear to be:
1. find a different way to lock all the reads of my
application variables (lock every read option
available in v4.5?)
2. check/run all queries, etc that need to be cached
in the application scope within the locked portion of
the app globals..
3. I'm confused and this will never be a problem
because nested locks work fine
Thanks again for the help
=====
Ken Beard, Developer
Stampede Network
Tampa, FL
(813)622-7655 ext.246
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
