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

This WebDNA talk-list message is from

2010

It keeps the original formatting. numero = 105503
interpreted = N
texte = This is a multi-part message in MIME format.--------------050606080103060309090003Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitKen,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,SteveKenneth Grome wrote:>> We will modify [append] to NOT automatically >> write to disk.>> >> Good move. This change will makes webdna behave as expected -- which is to commit only when we tell it to, and not every time we append a new record to the db.> > I definitely need this for a fast running auction system I'm writing. Too many writes to disk will delay the server's response times and make the auction functionally impossible.>>>>> t--------------050606080103060309090003Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: 7bitKen,

As Chris mentioned, I found that [append] was always writing to diskafter sending out a large email blast announcing a contest and at theonset of the rush of customers filling out and submitting the form atthe rate of a few within seconds of each other, I ended up with (2)duplicate records being [appended] out of several thousand recordswritten. 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 makesperfect sense for speed. However, I am still a little foggy as to whento use [commitdatabase]. With your upcoming auction project, I amhoping that you could give me some in site as to how often or when touse [commitdatabase]. First, do records written to RAM eventually getwrittento disk to free memory on their own or is [commitdatabase] alwayseventually required? Chris did try to explain to mewhere to use [commitdatabase] but I am still a bit unsure how, when andwhere to use [commitdatabase]. Particularly in a situation such as acontest or auction where there will be a high volume of records beingadded in a very short period of time.

Thanks,
Steve

Kenneth Grome wrote:





We will modify [append] to NOT automatically write to disk.    





Good move.  This change will makes webdna behave as expected -- which is to commit only when we tell it to, and not every time we append a new record to the db.  



I definitely need this for a fast running auction system I'm writing.  Too many writes to disk will delay the server's response times and make the auction functionally impossible.  



t--------------050606080103060309090003-- 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)

This is a multi-part message in MIME format.--------------050606080103060309090003Content-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitKen,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,SteveKenneth Grome wrote:>> We will modify [append] to NOT automatically >> write to disk.>> >> Good move. This change will makes webdna behave as expected -- which is to commit only when we tell it to, and not every time we append a new record to the db.> > I definitely need this for a fast running auction system I'm writing. Too many writes to disk will delay the server's response times and make the auction functionally impossible.>>>>> t--------------050606080103060309090003Content-Type: text/html; charset=ISO-8859-1Content-Transfer-Encoding: 7bitKen,

As Chris mentioned, I found that [append] was always writing to diskafter sending out a large email blast announcing a contest and at theonset of the rush of customers filling out and submitting the form atthe rate of a few within seconds of each other, I ended up with (2)duplicate records being [appended] out of several thousand recordswritten. 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 makesperfect sense for speed. However, I am still a little foggy as to whento use [commitdatabase]. With your upcoming auction project, I amhoping that you could give me some in site as to how often or when touse [commitdatabase]. First, do records written to RAM eventually getwrittento disk to free memory on their own or is [commitdatabase] alwayseventually required? Chris did try to explain to mewhere to use [commitdatabase] but I am still a bit unsure how, when andwhere to use [commitdatabase]. Particularly in a situation such as acontest or auction where there will be a high volume of records beingadded in a very short period of time.

Thanks,
Steve

Kenneth Grome wrote:





We will modify [append] to NOT automatically write to disk.    





Good move.  This change will makes webdna behave as expected -- which is to commit only when we tell it to, and not every time we append a new record to the db.  



I definitely need this for a fast running auction system I'm writing.  Too many writes to disk will delay the server's response times and make the auction functionally impossible.  



t--------------050606080103060309090003-- 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:

Multiple 'Users.db' files not possible (1997) Help name our technology! I found it (1997) Date and Comparisons (2002) Faxing orders in place of email (1997) Bug Report, maybe (1997) European Convention (2004) Re:HELP - NONE STOP DIGESTS. Digest for 4/24/97) (1997) Running _every_ page through WebCat ? (1997) sandboxes with 6.0 (2004) WebCat2 - [format thousands] (1997) shipcost (1997) Mac: LModelDirector bug fix (1997) problems with WebCat-Plugin () [WebDNA] looking for contract WebDNA coders (2011) Bug with periods in [math] variable names (2001) shipping costs (1999) [ConvertChars] problem (1997) WebDNA Codes in Secure Mode (1997) I give up!! (1997) HomePage Caution (1997)