Re: [WebDNA] To Commitdatabase or Not to Commitdatabase

This WebDNA talk-list message is from

2012


It keeps the original formatting.
numero = 108409
interpreted = N
texte = --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Govinda, Thanks for sticking to the thread and helping out... Do you know if is the same as having a at the end of = all/any [append] / [replace] within a codebase. Meaning that they are = equal but absolute better than Flushdatabases. ...or is better than [append] / [replace] or vise = versa. PP On 01/02/2012, at 21.32, Govinda wrote: >> So would a FlushDatabases, which I understand is All DB Written to = Disk be a "slower" task compared to a [commitdatabas....] after every = [replace/append] ? >=20 > I would assume that flushing all databases to disk would be slower. = About [FLUSHDATABASES] the manual says it, "causes all databases to be = written and closed". Why would you want to *close* the database just = to make sure the data is on disk? Then upon the very next operation = that involves that database, you have to load it all back into RAM = again. I would not close the database (remove it from RAM) unless = there was a reason to do so. I would also not commit to disk, nor = remove from RAM, ALL databases at once, unless there was a reason to do = so. =20 >=20 > [COMMITDATABASE..] lets you precisely write to disk (but not flush = from RAM) *just the database you specify*. >=20 >>=20 >> And how do you normally avoid data loss? Are you using the = [commitdatabase...] ?? >=20 > Well my clients are all over the map.. on different hosts, etc. Some = have auto-commit turned on via the admin interface.. Other = times/places I do use [commitdatabase...], specifically, when/where = needed. >=20 > -G--------------------------------------------------------- > 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 --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Govinda,

Thanks for sticking to the = thread and helping out...

Do you know if = <Automatically commit databases to = disk after modification> is the same as having a <commitdatabase = ...> at the end of all/any [append] / [replace] within a codebase. = Meaning that they are equal but absolute better than = Flushdatabases.

...or is = <commitdatabase...> better than [append] / [replace] or vise = versa.

PP



On 01/02/2012, at 21.32, Govinda = wrote:

So would a FlushDatabases, = which I understand is All DB Written to Disk be a "slower" task compared = to a [commitdatabas....] after every [replace/append] = ?

I would assume that flushing all databases to = disk would be slower.  About [FLUSHDATABASES] the manual says it, = "causes all databases to be written and closed".   Why would = you want to *close* the database just to make sure the data is on disk? =   Then upon the very next operation that involves that = database, you have to load it all back into RAM again.   I = would not close the database (remove it from RAM) unless there was a = reason to do so.  I would also not commit to disk, nor remove from = RAM, ALL databases at once, unless there was a reason to do so. =  

[COMMITDATABASE..] lets you precisely write to disk (but = not flush from RAM) *just the database you specify*.


And how do you = normally avoid data loss? Are you using the [commitdatabase...] = ??

Well my clients are all over the map.. on = different hosts, etc.   Some have auto-commit turned on via = the admin interface..   Other times/places I do use = [commitdatabase...], specifically, when/where = needed.

-G---------------------------------------------------------=
This message is sent to you because you are subscribed to
the = mailing list <talk@webdna.us>.
To = unsubscribe, E-mail to: <talk-leave@webdna.us>
archi= ves: http://mail.webdna.us/l= ist/talk@webdna.us
Bug Reporting: support@webdna.us

= --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Kenneth Grome 2012)
  2. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (christophe.billiottet@webdna.us 2012)
  3. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  4. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  5. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  6. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  7. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  8. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  9. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
  10. Re: [WebDNA] To Commitdatabase or Not to Commitdatabase (Govinda 2012)
  11. [WebDNA] To Commitdatabase or Not to Commitdatabase (Palle Bo Nielsen 2012)
--Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Govinda, Thanks for sticking to the thread and helping out... Do you know if is the same as having a at the end of = all/any [append] / [replace] within a codebase. Meaning that they are = equal but absolute better than Flushdatabases. ...or is better than [append] / [replace] or vise = versa. PP On 01/02/2012, at 21.32, Govinda wrote: >> So would a FlushDatabases, which I understand is All DB Written to = Disk be a "slower" task compared to a [commitdatabas....] after every = [replace/append] ? >=20 > I would assume that flushing all databases to disk would be slower. = About [flushdatabases] the manual says it, "causes all databases to be = written and closed". Why would you want to *close* the database just = to make sure the data is on disk? Then upon the very next operation = that involves that database, you have to load it all back into RAM = again. I would not close the database (remove it from RAM) unless = there was a reason to do so. I would also not commit to disk, nor = remove from RAM, ALL databases at once, unless there was a reason to do = so. =20 >=20 > [COMMITDATABASE..] lets you precisely write to disk (but not flush = from RAM) *just the database you specify*. >=20 >>=20 >> And how do you normally avoid data loss? Are you using the = [commitdatabase...] ?? >=20 > Well my clients are all over the map.. on different hosts, etc. Some = have auto-commit turned on via the admin interface.. Other = times/places I do use [commitdatabase...], specifically, when/where = needed. >=20 > -G--------------------------------------------------------- > 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 --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi Govinda,

Thanks for sticking to the = thread and helping out...

Do you know if = <Automatically commit databases to = disk after modification> is the same as having a <commitdatabase = ...> at the end of all/any [append] / [replace] within a codebase. = Meaning that they are equal but absolute better than = Flushdatabases.

...or is = <commitdatabase...> better than [append] / [replace] or vise = versa.

PP



On 01/02/2012, at 21.32, Govinda = wrote:

So would a FlushDatabases, = which I understand is All DB Written to Disk be a "slower" task compared = to a [commitdatabas....] after every [replace/append] = ?

I would assume that flushing all databases to = disk would be slower.  About [flushdatabases] the manual says it, = "causes all databases to be written and closed".   Why would = you want to *close* the database just to make sure the data is on disk? =   Then upon the very next operation that involves that = database, you have to load it all back into RAM again.   I = would not close the database (remove it from RAM) unless there was a = reason to do so.  I would also not commit to disk, nor remove from = RAM, ALL databases at once, unless there was a reason to do so. =  

[COMMITDATABASE..] lets you precisely write to disk (but = not flush from RAM) *just the database you specify*.


And how do you = normally avoid data loss? Are you using the [commitdatabase...] = ??

Well my clients are all over the map.. on = different hosts, etc.   Some have auto-commit turned on via = the admin interface..   Other times/places I do use = [commitdatabase...], specifically, when/where = needed.

-G---------------------------------------------------------=
This message is sent to you because you are subscribed to
the = mailing list <talk@webdna.us>.
To = unsubscribe, E-mail to: <talk-leave@webdna.us>
archi= ves: http://mail.webdna.us/l= ist/talk@webdna.us
Bug Reporting: support@webdna.us

= --Apple-Mail=_776DB703-01CA-404B-A747-D0AD0F2E9CDA-- Palle Bo Nielsen

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:

WebCat2: Items xx to xx shown, etc. (1997) Web Catalog vs. ICAT (1997) Calculate QTY (1998) Multiple serial numbers (1997) Add Unit Ship Cost to Cart (2000) [WebDNA] .html suffix (2014) God's Truth (1998) Serious WebDNA issue (2006) Extra equals signs with IE? (More debugging questions...) (1997) WebCat2b13MacPlugIn - [include] doesn't allow creator (1997) A few questions. . . (1997) Browser Info.txt -- newest additions? (1997) Email check problems (1999) WebMerchant - MacAuthorize (1999) Install Webcatalog under NT4.0 and Microsoft IIS 2.0 (1997) Reindexing a db with duplicate numbers... (1999) Odd Cart Behavior (1997) Email within tmpl ? (1997) Cart passing in URL... (2004) Too many wrong answers! (1998)