You shouldn't because you're not writing to the file on every request,
each request you're writing to an application scoped query. Every X
requests or on a scheduled basis you would dump the application query to
a file and run the bulk insert command.
Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers
Ben Lowndes wrote:
>
> hmm.... interesting.
>
> But wont I suffer from locking issues if I'm repeatedly writing to text file
> every time a user hits my page? The page does a bunch of DCOM stuff that
> takes a while, so ther ewill be multiple concurrent users...
>
> Or are you suggesting I go with loading it into an application struct and
> then periodically dump it into a text file and I then in turn perform the
> bulk insert?
>
> Thanks
>
> Ben.
>
> > -----Original Message-----
> > From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> > Sent: 21 November 2000 17:28
> > To: Fusebox
> > Subject: Re: Fusebox internal logging.
> >
> >
> > My only suggestion is to dump it to a boring old text file instead of a
> > WDDX string then use the bulk insert (assuming you're using SQL 7) like
> > this:
> >
> > BULK INSERT page_logs
> > FROM '#request.dbroot#\newlogs.txt'
> > WITH
> > (FIELDTERMINATOR = '|',
> > ROWTERMINATOR = '~')
> >
> > where #request.dbroot# is a drive on the SQL 7 box. like:
> >
> > <cfset request.dbroot="\\sqlserver\c$\temp">
> >
> > The reason for doing this is that you could dump 100 or a 1000 records
> > in like 20-30 milliseconds instead of looping over a query. Or storing
> > the raw WDDX.
> >
> > Steve Nelson
> >
> > Dan Haley wrote:
> > >
> > > Depending on your resources and access to the CF server, etc.
> > >
> > > - You could have a scheduled page that runs every few minutes
> > and takes the
> > > content of the application structure and processes it - takes
> > up a thread
> > > but no hit to an individual
> > > - Or, when you hit the "100" mark, dump the application
> > structure into a
> > > WDDX string and throw it in the database, then process these
> > outside of CF
> > > with something like a VB solution (pretty simple to work with
> > WDDX in VB)
> > > - Or, if the per page hit isn't too big from throwing raw data into the
> > > database, have a scheduled job inside the database process the
> > data instead
> > > of doing any in-page processing (scheduled jobs are really easy to do in
> > > Oracle - not available in Access)
> > >
> > > Hopefully these get you going in the right direction - I'm sure
> > there will
> > > be more ideas - probably even better!
> > >
> > > Dan
> > >
> > > -----Original Message-----
> > > From: Ben Lowndes [mailto:[EMAIL PROTECTED]]
> > > Sent: Tuesday, November 21, 2000 8:13 AM
> > > To: Fusebox
> > > Subject: Fusebox internal logging.
> > >
> > > Hello everybody.
> > >
> > > I remember a couple of months ago a discussion on this list concerning
> > > performing logging within Fusebox... I'm about to embark on a
> > similar thing
> > > and was wondering if anyone made any progress with this???
> > >
> > > I'm not actually doing full logging of every user as I don't
> > believe that
> > > would be efficent, but just on a section of my site. Here's what I was
> > > thinking:
> > >
> > > When a user hits the page I load all the data on them into a
> > request scoped
> > > structure. I then copy this into an app level struct holding many users
> > > details... When this app level struct contains a certain number of users
> > > details, e.g 100, I do a bulk insert into the Db of all these details.
> > >
> > > A few questions about this technique...
> > >
> > > What's the best way to do a Db insert from a large struct??? Do
> > I just loop
> > > over the struct inside a SQL query?
> > > When the 100th user (or what ever I set the limit to on the
> > struct to be)
> > > hits the page, the loading of their page will be considerably
> > slowed by the
> > > SQL insert, is there anyway to "spawn" another process, so it
> > wont affect
> > > any users??
> > >
> > > Thanks
> > >
> > > Ben.
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Structure your ColdFusion code with Fusebox. Get the official book at
> > > http://www.fusionauthority.com/bkinfo.cfm
> > >
> > > Archives: http://www.mail-archive.com/[email protected]/
> > > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
> > >
> > > The information contained in this message is privileged and
> > confidential. It is intended solely for the use of the named
> > recipient. If you are not the intended recipient, you are hereby
> > notified that any disclosure, copying, distribution, or use of
> > the contents of this transmission is strictly prohibited. If you
> > receive this message in error, please notify the sender
> > immediately. Thank you.
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > Structure your ColdFusion code with Fusebox. Get the official
> > book at http://www.fusionauthority.com/bkinfo.cfm
> > >
> > > Archives: http://www.mail-archive.com/[email protected]/
> > > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
> >
> > --
> > Steve Nelson
> > http://www.SecretAgents.com
> > Tools for Fusebox Developers
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Structure your ColdFusion code with Fusebox. Get the official
> > book at http://www.fusionauthority.com/bkinfo.cfm
> >
> > Archives: http://www.mail-archive.com/[email protected]/
> > Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Structure your ColdFusion code with Fusebox. Get the official book at
>http://www.fusionauthority.com/bkinfo.cfm
>
> Archives: http://www.mail-archive.com/[email protected]/
> Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
