As I mentioned a long time ago in the thread that Steve N. started,
what is really needed is a form of interprocess/CPU communication. Using
the registry and in effect polling, is a form of that. I do tend to
agree with your NT person though. I have seen and heard of registries
getting corrupted and that is a _very_ Bad Thing(tm). I tend to think
that heavy use of the registry (over time) is something that one should
approach very carefully.
Anyway, that's my $0.02...
Steve
At 10:35 AM 9/21/2000 -0700, Nat Papovich wrote:
>Yeah it would buckaroo. For every cached query, you have a registry key,
>with the value set to either 0 (don't mess) or 1 (get new data). After the
>query is run for that specific data change, you update that key to be 0
>again.
>
>This is gonna work, people. We just gotta figure out if the registry is a
>good place to do this. My NT/SQL guru says that it's not a Good Thing(tm) to
>mess with the registry so much, but I tell him, "Hey, Allaire used to store
>all client vars in the registry. It's gotta be stable!"
>
>Nat "Frames are cool, dude" Papovich
>ICQ 32676414
>
>
>-----Original Message-----
>From: Steve Nelson [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, September 21, 2000 10:01 AM
>To: Fusebox
>Subject: Re: cf_queryrefresh
>
>
>but wouldn't that refresh all of the servers in a cluster? I want a
>solution that would refresh a single query on all the servers and leaves
>the rest of the queries (that were unaffected by the data change) alone.
>
>Steve
>
>"McCollough, Alan" wrote:
>>
>> I think there might be an easier solution, but it is based on using a 100%
>> Microsoft solution...
>> Lets say you've got an NT server cluster, complete with an MS SQL 7 server
>> in there.
>>
>> In your fusebox code, you create a var called, oh, db_timespan. Now,
>here's
>> what to do. Have this var live up in app_globals.cfm, so it gets called
>> persistently. But you set the variable by doing a CFREGISTRY read, and
>let's
>> say you've got a Registry key called "{blah blah}\db_timespan". You could
>> use the value in this var to change the CACHEDAFTER or CACHEDWITHIN values
>> of a query, depends on what ya want to do.
>>
>> If you want to keep different timespans for different queries, you'd just
>> set up additional Registry keys.
>>
>> So okay, follow with me, you've set this var up so every time app_globals
>> gets called, you do a registry hit and get the new value. So what?
>>
>> I've found out you can do some mega-cool stuff with batch files in NT,
>> including changing registry settings on remote boxes. Uh, huh, you see the
>> idea coming together.
>>
>> For each "db_timespan" variable you have, you write a batch file that goes
>> out and updates the Registry keys for those time vars on all the CF
>servers
>> in your cluster; resetting the time to zero so as to force a fresh query.
>> You make sure this batch file is installed on each server in the cluster
>so
>> that any node on the cluster can execute the batch file.
>>
>> Now, you have two avenues you can take. The obvious one is to use
>CFEXECUTE
>> to call the batch file whenever you run a Insert/Update/Delete query. The
>> batch file gets called, and, ta-da, there ya go.
>>
>> The other solution, with its own benefits and caveats, is instead of
>housing
>> the batch files on the CF boxes and using CFEXECUTE, use your SQL server
>and
>> create a trigger for any Insert/Update/Delete actions. The trigger would
>> then start a XP_CMDSHELL extended stored proc (thats pure MS SQL, folks;
>it
>> ain't gonna be available elsewhere) to call the batch file.
>>
>> Alan McCollough
>> Web Programmer
>> Allaire Certified ColdFusion Developer
>> Alaska Native Medical Center
>>
>> > -----Original Message-----
>> > From: Steve Nelson [SMTP:[EMAIL PROTECTED]]
>> > Sent: Thursday, September 21, 2000 3:46 AM
>> > To: Fusebox
>> > Subject: Re: cf_queryrefresh
>> >
>> > The tag is not worth it. All it really does is set the timespan in the
>> > cachedwithin attribute to #createtimespan(0,0,0,0)# when you set
>> > attributes.refresh="yes"
>> > #createtimespan(1,0,0,0)# when you set attributes.refresh="no" I was
>being
>> > lazy when i wrote that. At the time i hadn't thought up what happens
>when
>> > you have clustered servers.
>> >
>> > A much better solution is doing a thing I call the "Synchronization
>> > Server". This will allow you to keep multiple clustered servers in
>Sync.
>> > It's still just a theory, but if it
>> > actually works we'll have a session on it at the next Fusebox
>conference,
>> > because it is way cool.
>> >
>> > http://www.fusebox.org/theories/sync_server/
>> >
>> > Steve Nelson
>> >
>> > "Andrew Sleigh (Worth Media)" wrote:
>> >
>> > > Does anyone know where I can get hold of the <queryrefresh> tag that
>> > Steve
>> > > Nelson mentions in his spec on fusebox.org?
>> > >
>> > > the URL is
>> > >
>> > >
>> >
>http://www.fusebox.org/specifications/largescale/index.cfm?fuseaction=quer
>> > yf
>> > > iles
>> > >
>> > > but the link seems to have died....
>> > >
>> > > Andy
>> > >
>> > >
>> >
>--------------------------------------------------------------------------
>> > ----
>> > > 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.
>> >
>> >
>--------------------------------------------------------------------------
>> > ----
>> > 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.
>>
>----------------------------------------------------------------------------
>--
>> 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.
>----------------------------------------------------------------------------
>--
>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.
>---------------------------------------------------------------------------
---
>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.
>
--
Stephen Garrett
GPS
[EMAIL PROTECTED] (360) 896-2714
ICQ# 10776767
------------------------------------------------------------------------------
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.
