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:

Summary search -- speed (1997) Restart of DBserver (1997) WebCatalog and Webstar 3.02 (1998) problems with 2 tags (1997) Websited Development (1999) Macauth: Dates and No Scripting... (1997) Using WC for Bulk Emailings (1997) WebCat b15 Mac plug-in (1997) Card clearance, problems - solutions? (1997) Nav. 4 probs with cart - Serious problem (1997) Running 2 two WebCatalog.acgi's (1996) How did *you* learn Web Catalog? (2000) [WebDNA] Clean URLS job - will pay (2010) Altavista causes a problem? (1998) [purgeDatabase], [replaceChars] and others ... (1997) Setting up shop (1997) help (2001) Still having install problems (2000) [OT] Connect to MySQL (Solved) (2004) WebMerchant Error (1998)