Re: Webcat DB's over appletalk

This WebDNA talk-list message is from

2003

It keeps the original formatting. numero = 48436
interpreted = N
texte = Alex .. I've read this a few times now and I can think of is Why ?? Get anOSX machine - run a whole bunch of server apps, never crash .. No hasslesurely.> OK, settle a debate for me.> > In a discussion about the viability of the following scenario:> > CPU A - MACOS 9.x> Running Web* and webcat 4.x> (also running other apps such as EIMS and Rumpus)> > CPU B - MACOS 9.x> Running NO APPS> > > CPU A mounts CPU B at startup using file sharing through Appletalk, though I> suppose 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 to> the mounted drive on CPU A.> > At first it seemed that there would be a big performance issue, but then> again, performance would only be an issue when opening or committing the DB> (thanks to webCAT and RAM DBs) --- and searching and general usability> shouldn'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 as> well.> > Then there was the discussion of having multiple CPU's (CPU C) having CPU B> mounted as well. Instantly we start thinking about multiple servers all> opening the same DB file.> > Kay this works if the information isn't changing. It truly does allow you to> farm off the same data __UNTIL__ you need to update it.> > Alright, clearly updating from 2 different places would/could cause problems> if CPU A overwrites the db on CPU B only to have CPU C try to update B again> later wiping out the changes A made ;-)> > But, we are debating how bad it would be to approach the updating a bit> differently....> > > 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 is> doing 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 single> file system this seems like a hack and might be slow. But don't you think> that if the DBs were not too enormous, and that your rate of change to> search/retrieve was low (which ours are almost ALWAYS low!), that the impact> might be trivial on a FAST CPU/DRIVE --- effectively opening up DB farming> to many machines.> > I know in theory that the 'potential' for information loss for writes done> at 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 for> the few seconds that might be needed -- or way less) so wait-for-file to> append your changes.> > > Seems intriguing. Just wondering what the real impact would be on some of> the newer crotch-rocket macs performance wise.> > > Am I missing something brutally obvious?> > Alex> > > Alex J McCombie New World Media> Chief Information Officer Drawer 607> 800/724.8973 Fair Haven, NY 13064> Alex@NewWorldMedia.com http://OurClients.com> > Interface 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/-------------------------------------------------------------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)

Alex .. I've read this a few times now and I can think of is Why ?? Get anOSX machine - run a whole bunch of server apps, never crash .. No hasslesurely.> OK, settle a debate for me.> > In a discussion about the viability of the following scenario:> > CPU A - MACOS 9.x> Running Web* and webcat 4.x> (also running other apps such as EIMS and Rumpus)> > CPU B - MACOS 9.x> Running NO APPS> > > CPU A mounts CPU B at startup using file sharing through Appletalk, though I> suppose 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 to> the mounted drive on CPU A.> > At first it seemed that there would be a big performance issue, but then> again, performance would only be an issue when opening or committing the DB> (thanks to webCAT and RAM DBs) --- and searching and general usability> shouldn'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 as> well.> > Then there was the discussion of having multiple CPU's (CPU C) having CPU B> mounted as well. Instantly we start thinking about multiple servers all> opening the same DB file.> > Kay this works if the information isn't changing. It truly does allow you to> farm off the same data __UNTIL__ you need to update it.> > Alright, clearly updating from 2 different places would/could cause problems> if CPU A overwrites the db on CPU B only to have CPU C try to update B again> later wiping out the changes A made ;-)> > But, we are debating how bad it would be to approach the updating a bit> differently....> > > 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 is> doing 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 single> file system this seems like a hack and might be slow. But don't you think> that if the DBs were not too enormous, and that your rate of change to> search/retrieve was low (which ours are almost ALWAYS low!), that the impact> might be trivial on a FAST CPU/DRIVE --- effectively opening up DB farming> to many machines.> > I know in theory that the 'potential' for information loss for writes done> at 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 for> the few seconds that might be needed -- or way less) so wait-for-file to> append your changes.> > > Seems intriguing. Just wondering what the real impact would be on some of> the newer crotch-rocket macs performance wise.> > > Am I missing something brutally obvious?> > Alex> > > Alex J McCombie New World Media> Chief Information Officer Drawer 607> 800/724.8973 Fair Haven, NY 13064> Alex@NewWorldMedia.com http://OurClients.com> > Interface 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/-------------------------------------------------------------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/ Alain Russell

DOWNLOAD WEBDNA NOW!

Re: Webcat DB's over appletalk

2003

Top Articles:

Related Readings: