Temp DB (Was freeze)

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 47644
interpreted = N
texte = 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. :-(AlexI 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.comInterface 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/ 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)
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. :-(AlexI 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.comInterface 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/ Alex McCombie

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:

problem (how to mark orders as 'opened') (1998) Date calculation problems (1997) WebCatalog stalls (1998) searchable list archive (1997) Webcat2, WebCommerce, Mod 10 etc. (1997) WebCat2_Mac RETURNs in .db (1997) Summing a field full of numbers ... (1997) WebDNA dying or ... ? (2005) autosensing lanague selection (1997) WebDNA Quick Reference (Reserved Words) (2000) Next X hits (1996) Search with Special Chars (1997) [Listfiles] vs Netfinder (1997) service stop and restart (1997) Https not showing products (2004) [Include] within a .dna file *further weirdness* (2005) Writing to PDF (2003) 4.5 Install Error (2003) WebCatalog for Postcards ? (1997) [sendmail] questions... (1997)