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

This WebDNA talk-list message is from

2010

It keeps the original formatting. numero = 105511
interpreted = N
texte = 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 Associated Messages, from the most recent to the oldest:

Re: [WebDNA] [append] to NOT always write to disk (Steve Raslevich 2010)
Re: [WebDNA] [append] to NOT always write to disk (Kenneth Grome 2010)
[WebDNA] [append] to NOT always write to disk (Steve Raslevich 2010)

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 Kenneth Grome

DOWNLOAD WEBDNA NOW!

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

2010

Top Articles:

Related Readings: