Webcat DB's over appletalk

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 48419
interpreted = N
texte = OK, settle a debate for me.In a discussion about the viability of the following scenario:CPU A - MACOS 9.xRunning Web* and webcat 4.x(also running other apps such as EIMS and Rumpus)CPU B - MACOS 9.xRunning NO APPSCPU A mounts CPU B at startup using file sharing through Appletalk, though Isuppose it could be through TCPIP as well but Appletalk seems faster.The webcat DB files are stored on the CPU B and accessed through an alias tothe mounted drive on CPU A.At first it seemed that there would be a big performance issue, but thenagain, performance would only be an issue when opening or committing the DB(thanks to webCAT and RAM DBs) --- and searching and general usabilityshouldn't be effected at all.Kay, so performance is only an issue on DB opening.There is some benefit of having critical data on a CPU running no apps aswell.Then there was the discussion of having multiple CPU's (CPU C) having CPU Bmounted as well. Instantly we start thinking about multiple servers allopening the same DB file.Kay this works if the information isn't changing. It truly does allow you tofarm off the same data __UNTIL__ you need to update it.Alright, clearly updating from 2 different places would/could cause problemsif CPU A overwrites the db on CPU B only to have CPU C try to update B againlater wiping out the changes A made ;-)But, we are debating how bad it would be to approach the updating a bitdifferently....Concept: DB = 1000 records and say 20 fields. Typical small-mid sized DB. When it comes time to update we employ a system similar to what SMSI isdoing to protect data during a write (temp DB). (this part is not fleshed out yet)WHEN A CHANGE IS NEEDED---close the still unchanged DB---Reopen it---Make the change---Commit the db Now I fully understand that compared to the current & elegant singlefile system this seems like a hack and might be slow. But don't you thinkthat if the DBs were not too enormous, and that your rate of change tosearch/retrieve was low (which ours are almost ALWAYS low!), that the impactmight be trivial on a FAST CPU/DRIVE --- effectively opening up DB farmingto many machines.I know in theory that the 'potential' for information loss for writes doneat exactly the same time would still exist. There might even be some simple'small file movement' way (file in the dir means someone is editing it forthe few seconds that might be needed -- or way less) so wait-for-file toappend your changes.Seems intriguing. Just wondering what the real impact would be on some ofthe newer crotch-rocket macs performance wise.Am I missing something brutally obvious?AlexAlex J McCombie New World MediaChief Information Officer Drawer 607800/724.8973 Fair Haven, NY 13064Alex@NewWorldMedia.com http://OurClients.comInterface Designer WebDNA Programmer Database Designer-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Associated Messages, from the most recent to the oldest:

Re: Webcat DB's over appletalk (Alex McCombie 2003) Re: Webcat DB's over appletalk (Alain Russell 2003) Webcat DB's over appletalk (Alex McCombie 2003)

OK, settle a debate for me.In a discussion about the viability of the following scenario:CPU A - MACOS 9.xRunning Web* and webcat 4.x(also running other apps such as EIMS and Rumpus)CPU B - MACOS 9.xRunning NO APPSCPU A mounts CPU B at startup using file sharing through Appletalk, though Isuppose it could be through TCPIP as well but Appletalk seems faster.The webcat DB files are stored on the CPU B and accessed through an alias tothe mounted drive on CPU A.At first it seemed that there would be a big performance issue, but thenagain, performance would only be an issue when opening or committing the DB(thanks to webCAT and RAM DBs) --- and searching and general usabilityshouldn't be effected at all.Kay, so performance is only an issue on DB opening.There is some benefit of having critical data on a CPU running no apps aswell.Then there was the discussion of having multiple CPU's (CPU C) having CPU Bmounted as well. Instantly we start thinking about multiple servers allopening the same DB file.Kay this works if the information isn't changing. It truly does allow you tofarm off the same data __UNTIL__ you need to update it.Alright, clearly updating from 2 different places would/could cause problemsif CPU A overwrites the db on CPU B only to have CPU C try to update B againlater wiping out the changes A made ;-)But, we are debating how bad it would be to approach the updating a bitdifferently....Concept: DB = 1000 records and say 20 fields. Typical small-mid sized DB. When it comes time to update we employ a system similar to what SMSI isdoing to protect data during a write (temp DB). (this part is not fleshed out yet)WHEN A CHANGE IS NEEDED---close the still unchanged DB---Reopen it---Make the change---Commit the db Now I fully understand that compared to the current & elegant singlefile system this seems like a hack and might be slow. But don't you thinkthat if the DBs were not too enormous, and that your rate of change tosearch/retrieve was low (which ours are almost ALWAYS low!), that the impactmight be trivial on a FAST CPU/DRIVE --- effectively opening up DB farmingto many machines.I know in theory that the 'potential' for information loss for writes doneat exactly the same time would still exist. There might even be some simple'small file movement' way (file in the dir means someone is editing it forthe few seconds that might be needed -- or way less) so wait-for-file toappend your changes.Seems intriguing. Just wondering what the real impact would be on some ofthe newer crotch-rocket macs performance wise.Am I missing something brutally obvious?AlexAlex J McCombie New World MediaChief Information Officer Drawer 607800/724.8973 Fair Haven, NY 13064Alex@NewWorldMedia.com http://OurClients.comInterface Designer WebDNA Programmer Database Designer-------------------------------------------------------------This message is sent to you because you are subscribed to the mailing list .To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ Alex McCombie

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:

ODBC problems between webcat and filemaker pro (2001) Logging purchases (1997) More on the email templates (1997) Carts & cookies (1999) using showpage and showcart commands (1996) WC2b12: Yes, Formulas.db is for real (1997) Errata: WCS Newbie question (1997) Date Formats (1997) WebCat2b13MacPlugIn - [include] (1997) Here's how to kill a Butler Database. (1997) duplicate cart numbers - New P3P Rule (2002) could someone please try this - it's very quick and easy (2000) email (1998) webcat2b12 CGI -- Date comparisons (1997) ShowIF Question (2000) Add a field to the error log? (1997) Bug Report, maybe (1997) suffix mapping for NT? (1997) Full text search (1999) WebCat with WebTen (1998)