Re: AutoCommit Preference?
This WebDNA talk-list message is from 1998
It keeps the original formatting.
numero = 16464
interpreted = N
texte = >>What triggers this auto-commit activity that makes it slower when it's On than when it's Off? > >If any databases are dirty after the page is returned, they are written to disk. That takes some time, but is of course safer if you have an unstable server. > >>Is it triggered every time a page is requested? > >Yes, but if no databases are dirty, then there is no slowdown.All I was trying to figure out is whether or not having the AutoCommit set to T is going to make WebCat slower than if I continued to use [closedatabase] tags after all my replace and delete commands, like I've been doing all along.From what you're telling me, it seems like using AutoCommit would be even faster than using [closedatabase] tags -- because the [closedatabase] tag actually purges the data from RAM in addition to writing the data to disk, which means using the [closedatabase] tag will always require reloading of the data from disk the next time the db is called.So *assuming* that the AutoCommit checking does NOT slow down the server when the db's are clean, using the new AutoCommit feature would actually be FASTER than using [closedatabase] tags, right? Ah, but how would this compare with using [commitdatabase] tags instead of [closedatabase] tags?Will setting AutoCommit to T be faster than setting it to F and using [commitdatabase] tags after replace and delete commands?Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net
Associated Messages, from the most recent to the oldest:
>>What
triggers this auto-commit activity that makes it slower when it's On than when it's Off? > >If any databases are dirty after the page is returned, they are written to disk. That takes some time, but is of course safer if you have an unstable server. > >>Is it triggered every time a page is requested? > >Yes, but if no databases are dirty, then there is no slowdown.All I was trying to figure out is whether or not having the AutoCommit set to T is going to make WebCat slower than if I continued to use
[closedatabase] tags after all my replace and delete commands, like I've been doing all along.From what you're telling me, it seems like using AutoCommit would be even faster than using
[closedatabase] tags -- because the
[closedatabase] tag actually purges the data from RAM in addition to writing the data to disk, which means using the
[closedatabase] tag will always require reloading of the data from disk the next time the db is called.So *assuming* that the AutoCommit checking does NOT slow down the server when the db's are clean, using the new AutoCommit feature would actually be FASTER than using
[closedatabase] tags, right? Ah, but how would this compare with using
[commitdatabase] tags instead of
[closedatabase] tags?Will setting AutoCommit to T be faster than setting it to F and using
[commitdatabase] tags after replace and delete commands?Sincerely, Ken Grome 808-737-6499 WebDNA Solutions mailto:ken@webdna.net http://www.webdna.net
Kenneth Grome
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:
No Answer on Web Merchant Problem? (2001)
wierd... [Was] User Authentication (2003)
.tmp files (2000)
[WebDNA] To Commitdatabase or Not to Commitdatabase (2012)
WebCatalog2 Feature Feedback (1996)
[WebDNA] Happy New Year! (2009)
W* 3.x & WebCat + WebMerchant (1998)
[WebDNA] Upload file to mysql (2017)
show all problem (1997)
No luck with taxes (1997)
NT Manual (1997)
WebCatalog for Postcards ? (1997)
AJAX with WebDNA (2006)
[OT] Discussion forum, last visit, Cookie, ... (2003)
Ok here is a question? (1997)
WebCatalog for Postcards ? (1997)
Doing VALIDCARD right? (1998)
Autonumber (2003)
HTML authentication HTML page (1999)
Add more fields to an existent data base (1997)