[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:

Emailer (WebCat2) (1997) WebCat B13 Mac CGI -- Frames question (1997) Width & Height (1998) Major Security Hole (solution with Welcome) (1998) My server admin needs help ... (2004) Date Sorting (1997) Execute Applescript (1997) Weird problems with [SHOWIF]s (1997) PCS Customer submissions ? (1997) WebSTAR/WebCat is serving .db files! (1999) Almost Real Time (2002) Displaying photo attached to first record (1997) webcat serving up 2+ versions of the same db? (2000) problems with 2 tags (1997) Big Databases (1997) Extra carriage returns (1999) [showif [numfound]=0]? (2000) formula's (1998) wrong input values? (1997) Problems with [Search] param - Mac Plugin b15 (1997)