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

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

2010

Top Articles:

Related Readings: