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:

Virtual Postcards (1998) Two stores, one server (1998) Problem: 3.0 doesn't update carts (1997) Old $ commands and migration (2004) YACBQ.....(Yet another checkbox question) (2000) WebCat2b12 forgets serial # (1997) Search design (1997) WCf2 and nested tags (1997) Cookies (1999) Shopping Cart variation... (1997) GuestBook example (1997) Help! WebCat2 bug (1997) Whats going on? (2000) WebCatalog books and othre resources (2001) WebMerchant Processing criteria for AuthorizeNet (2000) Search in 2 or more catalogs (1997) Emailer port change (1997) Generating Report Totals (1997) table tag suggestion (2003) RE: Can't get appendfile to work (1997)