Re: Temp DB (Was freeze)

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 47646
interpreted = N
texte = Even if you're preference isn't set to commit automatically, it will flush to disk periodically after a certain number of appends.>On 2/10/03 9:54 PM, Kenneth Grome wrote: > > >Unless I am missing something, how did you make the leap to this happening >on every append, replace or delete. Isnt this true that unless your prefs >are set to commit on every change (I don't know of anyone that does that), >this procedure is ONLY going to happen when you tell the app to commit >(write) the db to disk? > > >So if we look at the steps you outlined below: > >1. I disagree (again unless I missed something) >2. This is the same as before as one DB HAS to be written at least >3. This is new but a delete is nothing compared to a write >4. Again, a file rename & a delete are miniscule compared to a write. > > >And as far as not being opened in the ram cache, the file being written to >the disk under a temp name, and then renamed to the original name would be >seen by Webcat as the same file as it uses path names to identify the file. > >Am I missing something here ken, or have you done some testing on this? >Because, don't take this the wrong way, but there seems to be an awful lot >of assumption taking place in this thread, many of which don't really seem >to make sense to me. :-( > >Alex > >I changed the thread title because the freeze was isolated and resolved. > > >> In other words, instead of just writing the changes to RAM or to a >> single disk file, this new preference does the following: >> >> 1- closes a db upon every append, replace and delete >> 2- writes a new temporary db file to disk >> 3- deletes the original db file >> 4- renames the temporary file to the original db file name >> >> And of course since the original db file has been deleted and another >> file has taken its place, the new file is not yet open in webdna's >> RAM cache ... so it takes additional time for the new db file to be >> opened before any visitor can use it. >> >> And if the request that opens the closed db file is an append, >> replace or delete, the file will be immediately closed and replaced >> again -- thus eliminating all the benefits of RAM-caching of data. >> >> Clearly this takes a lot more time than the old way of writing to a >> db, especially with large db files and slow OS's ... > >Alex J McCombie New World Media >Chief Information Officer Drawer 607 >800/724.8973 Fair Haven, NY 13064 >Alex@NewWorldMedia.com http://OurClients.com > >Interface Designer WebDNA Programmer Database Designer > > > >------------------------------------------------------------- >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to >Web Archive of this list is at: http://webdna.smithmicro.com/-- --------------------------------- John A. Hill Oak Hill Software Website Development/Consulting john@oakhillsoftware.com------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: Temp DB (Was freeze) (Alain Russell 2003)
  2. Re: Temp DB (Was freeze) (Alex McCombie 2003)
  3. Re: Temp DB (Was freeze) (John Hill 2003)
  4. Re: Temp DB (Was freeze) (Alain Russell 2003)
  5. Re: Temp DB (Was freeze) (Alex McCombie 2003)
  6. Re: Temp DB (Was freeze) (Alex McCombie 2003)
  7. Re: Temp DB (Was freeze) (John Hill 2003)
  8. Re: Temp DB (Was freeze) (Kenneth Grome 2003)
  9. Temp DB (Was freeze) (Alex McCombie 2003)
Even if you're preference isn't set to commit automatically, it will flush to disk periodically after a certain number of appends.>On 2/10/03 9:54 PM, Kenneth Grome wrote: > > >Unless I am missing something, how did you make the leap to this happening >on every append, replace or delete. Isnt this true that unless your prefs >are set to commit on every change (I don't know of anyone that does that), >this procedure is ONLY going to happen when you tell the app to commit >(write) the db to disk? > > >So if we look at the steps you outlined below: > >1. I disagree (again unless I missed something) >2. This is the same as before as one DB HAS to be written at least >3. This is new but a delete is nothing compared to a write >4. Again, a file rename & a delete are miniscule compared to a write. > > >And as far as not being opened in the ram cache, the file being written to >the disk under a temp name, and then renamed to the original name would be >seen by Webcat as the same file as it uses path names to identify the file. > >Am I missing something here ken, or have you done some testing on this? >Because, don't take this the wrong way, but there seems to be an awful lot >of assumption taking place in this thread, many of which don't really seem >to make sense to me. :-( > >Alex > >I changed the thread title because the freeze was isolated and resolved. > > >> In other words, instead of just writing the changes to RAM or to a >> single disk file, this new preference does the following: >> >> 1- closes a db upon every append, replace and delete >> 2- writes a new temporary db file to disk >> 3- deletes the original db file >> 4- renames the temporary file to the original db file name >> >> And of course since the original db file has been deleted and another >> file has taken its place, the new file is not yet open in webdna's >> RAM cache ... so it takes additional time for the new db file to be >> opened before any visitor can use it. >> >> And if the request that opens the closed db file is an append, >> replace or delete, the file will be immediately closed and replaced >> again -- thus eliminating all the benefits of RAM-caching of data. >> >> Clearly this takes a lot more time than the old way of writing to a >> db, especially with large db files and slow OS's ... > >Alex J McCombie New World Media >Chief Information Officer Drawer 607 >800/724.8973 Fair Haven, NY 13064 >Alex@NewWorldMedia.com http://OurClients.com > >Interface Designer WebDNA Programmer Database Designer > > > >------------------------------------------------------------- >This message is sent to you because you are subscribed to > the mailing list . >To unsubscribe, E-mail to: >To switch to the DIGEST mode, E-mail to >Web Archive of this list is at: http://webdna.smithmicro.com/-- --------------------------------- John A. Hill Oak Hill Software Website Development/Consulting john@oakhillsoftware.com------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ John Hill

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

[WebDNA] Question for WSC ... (2008) redirect from the errorsMessages.db entry (1997) Re:[ShowIf] and empty fields (1997) No luck with taxes (1997) Trouble with formula.db (1997) emailer (1997) SSL and reg web* (1997) WebCatalog/Mac 2.1b2 - PIXO (1997) WebCat2 beta FTP site (1997) WebCatalog 2.0 & WebDNA docs in HTML ... (1997) WebDelivery downloads alias, not original ? (1997) b12 cannot limit records returned and more. (1997) Re:2nd WebCatalog2 Feature Request (1996) [WebDNA] Broken Links on Webdna.us Website (2011) Re:EMail not being sent (1999) WebCat & WebTen (1997) Re1000001: Setting up shop (1997) WebDNA Solutions ... sorry! (1997) Auto conversion of URLs? (1998) Rollovers (1999)