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 SoftwareWebsite 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:
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 SoftwareWebsite 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)