Re: [WebDNA] [append] to NOT always write to disk

This WebDNA talk-list message is from

2010


It keeps the original formatting.
numero = 105515
interpreted = N
texte = This is a multi-part message in MIME format. --------------020403000508050600000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Ken, Thanks for taking the time to explain this in detail. I have a much better handle on how and when I will have my various databases written to disk. Thank you kindly, Steve Kenneth Grome wrote: > Hi Steve, > > The auction I'm working on will run for only an hour. I don't want to write the db's to disk at all during this time. If I should lose the auction data from memory during this hour, I will simply repeat the auction and hope that the next time I don't have the same problem. > > As far as when to use commitdatabase, I can't really tell you when to use it in your auction because yours may be dramatically different from mine. I won't be using it at all in my auction during the hour that I'll be accepting bids ... > > But as soon as the auction is over a script that uses a [flushdatabases] tag will write all the open db's to disk. Then it will email these db files to my gmail account -- so that the data is immediately replicated on another server where I can retrieve it in case my server craps out on me before I have a chance to download the db files manually from my own server. > > >> Do records written to RAM eventually get written to disk >> to free memory on their own or is [commitdatabase] >> always eventually required? >> > > They do not get written to disk for the purpose of freeing memory UNLESS another db needs to be opened and there's not enough memory for it to be opened. In this situation webdna will close one or more of the currently open db's to make room for the new one that needs to be opened. > > Naturally it is best to avoid having so little memory that webdna must do this, because webdna is most efficient when it can keep all the necessary db's open in memory. But as far as I know, the only time webdna will write its db's to disk is when you tell it to, via one of these methods: > > 1- a setting in the prefs that can make it write all db changes to disk immediately > 2- a commitdatabase tag which writes that one db to disk > 3- a closedatabase tag which writes that one db to disk then purge it from memory > 4- a flushdatabases tag which writes all db's to disk then purges them all from memory > > And as we have recently learned, we have no choice in this situation: > > 5- an append context which always writes to disk > > So ... when WSC gets the append behavior fixed we will regain control over when all our db's are written to disk. Until then we can only control the "write to disk" behavior of webdna in situations where append is not being used. > > Sincerely, > Kenneth Grome > > (Note to self: If WSC does not have the append bug fixed by the time I need to launch my auction, I should pre-populate my bids.db with 1000 blank bids for every registered auction participant. Then instead of "appending" new bids to this db like I was going to do before I learned about this bug, I can "replace" those blank values one at a time as the bids come in. This would seem to be the only way for me to insure that webdna does not write any data to disk during the hour-long auction, assuming I;m suing one of the current versions of webdna.) > > > > > > > > >> Ken, >> >> As Chris mentioned, I found that [append] was always writing to disk >> after sending out a large email blast announcing a contest and at the >> onset of the rush of customers filling out and submitting the form at >> the rate of a few within seconds of each other, I ended up with (2) >> duplicate records being [appended] out of several thousand records >> written. This is what got me digging into it. >> >> I am fairly new to WebDNA and writing databases to RAM and selectively >> [committing] the database to disk is a new concept for me but makes >> perfect sense for speed. However, I am still a little foggy as to when >> to use [commitdatabase]. With your upcoming auction project, I am hoping >> that you could give me some in site as to how often or when to use >> [commitdatabase]. First, do records written to RAM eventually get >> written to disk to free memory on their own or is [commitdatabase] >> always eventually required? Chris did try to explain to me where to use >> [commitdatabase] but I am still a bit unsure how, when and where to use >> [commitdatabase]. Particularly in a situation such as a contest or >> auction where there will be a high volume of records being added in a >> very short period of time. >> >> Thanks, >> Steve >> > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > > -- Steve Raslevich President/CEO Northern Sound & Light, Inc. 11 Shingiss Street McKees Rocks, Pennsylvania 15136 Phone: (412) 331-1000 Fax: (412) 331-1035 http://www.northernsound.net --------------------------------------------------------------------------------------------------------------------------------------- This Email and any files transmitted with it contain confidential, non-public information intended solely for the use of the individual to whom or the entity to which they are addressed. Unauthorized use, reproduction, distribution or communication of this message or any information contained or attached to this message is strictly prohibited and may be unlawful. If you have received this email in error please notify the sender immediately by e-mail or contact Northern Sound & Light at frontdesk@northernsound.net or (412) 331-1000. --------------------------------------------------------------------------------------------------------------------------------------- --------------020403000508050600000408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Ken,

Thanks for taking the time to explain this in detail. I have a much better handle on how and when I will have my various databases written to disk.

Thank you kindly,
Steve

Kenneth Grome wrote: 
Hi Steve,The auction I'm working on will run for only an hour.  I don't want to write the db's to disk at all during this time.  If I should lose the auction data from memory during this hour, I will simply repeat the auction and hope that the next time I don't have the same problem.As far as when to use commitdatabase, I can't really tell you when to use it in your auction because yours may be dramatically different from mine.  I won't be using it at all in my auction during the hour that I'll be accepting bids ...  But as soon as the auction is over a script that uses a [flushdatabases] tag will write all the open db's to disk.  Then it will email these db files to my gmail account -- so that the data is immediately replicated on another server where I can retrieve it in case my server craps out on me before I have a chance to download the db files manually from my own server.  
Do records written to RAM eventually get written to disk to free memory on their own or is [commitdatabase] always eventually required?    
They do not get written to disk for the purpose of freeing memory UNLESS another db needs to be opened and there's not enough memory for it to be opened.  In this situation webdna will close one or more of the currently open db's to make room for the new one that needs to be opened.  Naturally it is best to avoid having so little memory that webdna must do this, because webdna is most efficient when it can keep all the necessary db's open in memory.  But as far as I know, the only time webdna will write its db's to disk is when you tell it to, via one of these methods:1- a setting in the prefs that can make it write all db changes to disk immediately2- a commitdatabase tag which writes that one db to disk3- a closedatabase tag which writes that one db to disk then purge it from memory4- a flushdatabases tag which writes all db's to disk then purges them all from memoryAnd as we have recently learned, we have no choice in this situation:5- an append context which always writes to diskSo ... when WSC gets the append behavior fixed we will regain control over when all our db's are written to disk.  Until then we can only control the "write to disk" behavior of webdna in situations where append is not being used.Sincerely,Kenneth Grome(Note to self:  If WSC does not have the append bug fixed by the time I need to launch my auction, I should pre-populate my bids.db with 1000 blank bids for every registered auction participant.  Then instead of "appending" new bids to this db like I was going to do before I learned about this bug, I can "replace" those blank values one at a time as the bids come in.  This would seem to be the only way for me to insure that webdna does not write any data to disk during the hour-long auction, assuming I;m suing one of the current versions of webdna.)  
Ken,As Chris mentioned, I found that [append] was always writing to disk after sending out a large email blast announcing a contest and at the onset of the rush of customers filling out and submitting the form at the rate of a few within seconds of each other, I ended up with (2) duplicate records being [appended] out of several thousand records written. This is what got me digging into it.I am fairly new to WebDNA and writing databases to RAM and selectively [committing] the database to disk is a new concept for me but makes perfect sense for speed. However, I am still a little foggy as to when to use [commitdatabase]. With your upcoming auction project, I am hoping that you could give me some in site as to how often or when to use [commitdatabase]. First, do records written to RAM eventually get written to disk to free memory on their own or is [commitdatabase] always eventually required? Chris did try to explain to me where to use [commitdatabase] but I am still a bit unsure how, when and where to use [commitdatabase]. Particularly in a situation such as a contest or auction where there will be a high volume of records being added in a very short period of time.Thanks,Steve    
---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us  

-- Steve RaslevichPresident/CEONorthern Sound & Light, Inc.11 Shingiss StreetMcKees Rocks, Pennsylvania 15136Phone: (412) 331-1000Fax: (412) 331-1035http://www.northernsound.net---------------------------------------------------------------------------------------------------------------------------------------This Email and any files transmitted with it contain confidential, non-public information intended solely for the use of the individual to whom or the entity to which they are addressed. Unauthorized use, reproduction, distribution or communication of this message or any information contained or attached to this message is strictly prohibited and may be unlawful. If you have received this email in error please notify the sender immediately by e-mail or contact Northern Sound & Light at frontdesk@northernsound.net or (412) 331-1000.---------------------------------------------------------------------------------------------------------------------------------------
--------------020403000508050600000408-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] [append] to NOT always write to disk (Steve Raslevich 2010)
  2. Re: [WebDNA] [append] to NOT always write to disk (Kenneth Grome 2010)
  3. [WebDNA] [append] to NOT always write to disk (Steve Raslevich 2010)
This is a multi-part message in MIME format. --------------020403000508050600000408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Ken, Thanks for taking the time to explain this in detail. I have a much better handle on how and when I will have my various databases written to disk. Thank you kindly, Steve Kenneth Grome wrote: > Hi Steve, > > The auction I'm working on will run for only an hour. I don't want to write the db's to disk at all during this time. If I should lose the auction data from memory during this hour, I will simply repeat the auction and hope that the next time I don't have the same problem. > > As far as when to use commitdatabase, I can't really tell you when to use it in your auction because yours may be dramatically different from mine. I won't be using it at all in my auction during the hour that I'll be accepting bids ... > > But as soon as the auction is over a script that uses a [flushdatabases] tag will write all the open db's to disk. Then it will email these db files to my gmail account -- so that the data is immediately replicated on another server where I can retrieve it in case my server craps out on me before I have a chance to download the db files manually from my own server. > > >> Do records written to RAM eventually get written to disk >> to free memory on their own or is [commitdatabase] >> always eventually required? >> > > They do not get written to disk for the purpose of freeing memory UNLESS another db needs to be opened and there's not enough memory for it to be opened. In this situation webdna will close one or more of the currently open db's to make room for the new one that needs to be opened. > > Naturally it is best to avoid having so little memory that webdna must do this, because webdna is most efficient when it can keep all the necessary db's open in memory. But as far as I know, the only time webdna will write its db's to disk is when you tell it to, via one of these methods: > > 1- a setting in the prefs that can make it write all db changes to disk immediately > 2- a commitdatabase tag which writes that one db to disk > 3- a closedatabase tag which writes that one db to disk then purge it from memory > 4- a flushdatabases tag which writes all db's to disk then purges them all from memory > > And as we have recently learned, we have no choice in this situation: > > 5- an append context which always writes to disk > > So ... when WSC gets the append behavior fixed we will regain control over when all our db's are written to disk. Until then we can only control the "write to disk" behavior of webdna in situations where append is not being used. > > Sincerely, > Kenneth Grome > > (Note to self: If WSC does not have the append bug fixed by the time I need to launch my auction, I should pre-populate my bids.db with 1000 blank bids for every registered auction participant. Then instead of "appending" new bids to this db like I was going to do before I learned about this bug, I can "replace" those blank values one at a time as the bids come in. This would seem to be the only way for me to insure that webdna does not write any data to disk during the hour-long auction, assuming I;m suing one of the current versions of webdna.) > > > > > > > > >> Ken, >> >> As Chris mentioned, I found that [append] was always writing to disk >> after sending out a large email blast announcing a contest and at the >> onset of the rush of customers filling out and submitting the form at >> the rate of a few within seconds of each other, I ended up with (2) >> duplicate records being [appended] out of several thousand records >> written. This is what got me digging into it. >> >> I am fairly new to WebDNA and writing databases to RAM and selectively >> [committing] the database to disk is a new concept for me but makes >> perfect sense for speed. However, I am still a little foggy as to when >> to use [commitdatabase]. With your upcoming auction project, I am hoping >> that you could give me some in site as to how often or when to use >> [commitdatabase]. First, do records written to RAM eventually get >> written to disk to free memory on their own or is [commitdatabase] >> always eventually required? Chris did try to explain to me where to use >> [commitdatabase] but I am still a bit unsure how, when and where to use >> [commitdatabase]. Particularly in a situation such as a contest or >> auction where there will be a high volume of records being added in a >> very short period of time. >> >> Thanks, >> Steve >> > --------------------------------------------------------- > This message is sent to you because you are subscribed to > the mailing list . > To unsubscribe, E-mail to: > archives: http://mail.webdna.us/list/talk@webdna.us > Bug Reporting: support@webdna.us > > -- Steve Raslevich President/CEO Northern Sound & Light, Inc. 11 Shingiss Street McKees Rocks, Pennsylvania 15136 Phone: (412) 331-1000 Fax: (412) 331-1035 http://www.northernsound.net --------------------------------------------------------------------------------------------------------------------------------------- This Email and any files transmitted with it contain confidential, non-public information intended solely for the use of the individual to whom or the entity to which they are addressed. Unauthorized use, reproduction, distribution or communication of this message or any information contained or attached to this message is strictly prohibited and may be unlawful. If you have received this email in error please notify the sender immediately by e-mail or contact Northern Sound & Light at frontdesk@northernsound.net or (412) 331-1000. --------------------------------------------------------------------------------------------------------------------------------------- --------------020403000508050600000408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Ken,

Thanks for taking the time to explain this in detail. I have a much better handle on how and when I will have my various databases written to disk.

Thank you kindly,
Steve

Kenneth Grome wrote: 
Hi Steve,The auction I'm working on will run for only an hour.  I don't want to write the db's to disk at all during this time.  If I should lose the auction data from memory during this hour, I will simply repeat the auction and hope that the next time I don't have the same problem.As far as when to use commitdatabase, I can't really tell you when to use it in your auction because yours may be dramatically different from mine.  I won't be using it at all in my auction during the hour that I'll be accepting bids ...  But as soon as the auction is over a script that uses a [flushdatabases] tag will write all the open db's to disk.  Then it will email these db files to my gmail account -- so that the data is immediately replicated on another server where I can retrieve it in case my server craps out on me before I have a chance to download the db files manually from my own server.  
Do records written to RAM eventually get written to disk to free memory on their own or is [commitdatabase] always eventually required?    
They do not get written to disk for the purpose of freeing memory UNLESS another db needs to be opened and there's not enough memory for it to be opened.  In this situation webdna will close one or more of the currently open db's to make room for the new one that needs to be opened.  Naturally it is best to avoid having so little memory that webdna must do this, because webdna is most efficient when it can keep all the necessary db's open in memory.  But as far as I know, the only time webdna will write its db's to disk is when you tell it to, via one of these methods:1- a setting in the prefs that can make it write all db changes to disk immediately2- a commitdatabase tag which writes that one db to disk3- a closedatabase tag which writes that one db to disk then purge it from memory4- a flushdatabases tag which writes all db's to disk then purges them all from memoryAnd as we have recently learned, we have no choice in this situation:5- an append context which always writes to diskSo ... when WSC gets the append behavior fixed we will regain control over when all our db's are written to disk.  Until then we can only control the "write to disk" behavior of webdna in situations where append is not being used.Sincerely,Kenneth Grome(Note to self:  If WSC does not have the append bug fixed by the time I need to launch my auction, I should pre-populate my bids.db with 1000 blank bids for every registered auction participant.  Then instead of "appending" new bids to this db like I was going to do before I learned about this bug, I can "replace" those blank values one at a time as the bids come in.  This would seem to be the only way for me to insure that webdna does not write any data to disk during the hour-long auction, assuming I;m suing one of the current versions of webdna.)  
Ken,As Chris mentioned, I found that [append] was always writing to disk after sending out a large email blast announcing a contest and at the onset of the rush of customers filling out and submitting the form at the rate of a few within seconds of each other, I ended up with (2) duplicate records being [appended] out of several thousand records written. This is what got me digging into it.I am fairly new to WebDNA and writing databases to RAM and selectively [committing] the database to disk is a new concept for me but makes perfect sense for speed. However, I am still a little foggy as to when to use [commitdatabase]. With your upcoming auction project, I am hoping that you could give me some in site as to how often or when to use [commitdatabase]. First, do records written to RAM eventually get written to disk to free memory on their own or is [commitdatabase] always eventually required? Chris did try to explain to me where to use [commitdatabase] but I am still a bit unsure how, when and where to use [commitdatabase]. Particularly in a situation such as a contest or auction where there will be a high volume of records being added in a very short period of time.Thanks,Steve    
---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/list/talk@webdna.usBug Reporting: support@webdna.us  

-- Steve RaslevichPresident/CEONorthern Sound & Light, Inc.11 Shingiss StreetMcKees Rocks, Pennsylvania 15136Phone: (412) 331-1000Fax: (412) 331-1035http://www.northernsound.net---------------------------------------------------------------------------------------------------------------------------------------This Email and any files transmitted with it contain confidential, non-public information intended solely for the use of the individual to whom or the entity to which they are addressed. Unauthorized use, reproduction, distribution or communication of this message or any information contained or attached to this message is strictly prohibited and may be unlawful. If you have received this email in error please notify the sender immediately by e-mail or contact Northern Sound & Light at frontdesk@northernsound.net or (412) 331-1000.---------------------------------------------------------------------------------------------------------------------------------------
--------------020403000508050600000408-- Steve Raslevich

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] A new popuated field to a DB with 700.000 records (2009) Delete tag (2000) carts on MacOS X Server (2000) Plugin or CGI or both (1997) WebCatalog Technical Reference (1997) WebCat with WebTen (1998) RAM variables (1997) Searching multiple Databases (1997) Webstar 1.3.1 PPC (1997) WebCatalog2 Feature Feedback (1996) WebCatalog for Postcards ? (1997) New random discoveries? (2005) Multiple Stores and WebCatalog Prefs (1997) An easy one (1999) Problems with [Applescript] (1997) FileMaker Pro (1999) Sort Order on a page search (1997) A question on sub-categories (1997) [WebDNA] WebDNA future (2010) No Access warning when caching HTML files (1997)