On 18 Jul 2000 22:00:21 -0400, the world broke into rejoicing as Roland Roberts <[EMAIL PROTECTED]> said: > >>>>> "cbb" == Christopher Browne <[EMAIL PROTECTED]> writes: > cbb> A way around this would be to have ONE process devoted to > cbb> doing database updates, which would receive updates, one at a > cbb> time, that would thus be rather limited in size/time expense, > cbb> and then spawn, locally, a reader process to support each > cbb> user that would access data in a read-only manner. That can > cbb> scale pretty well even in the absence of threading (which is > cbb> tough to keep portable across platforms). > > Or skip to the chase with a real database. No, I'd argue for there to be components of _BOTH_. > Seriously, once there is break between everthing else and storage, the > storage can be implemented however. If you use the filesystem > directly, you have to manage all the multiple-read single-writer stuff > yourself and worry about deadlocks not being "too bad". Just foist it > off on a real database where someone else has worried about it; I'm > partial to Postgres myself and before I ran into gnucash started > laying out tables to keep track of accounting information. I'd love > to see hooks where I could plug in all of the database's strengths for > handling multiuser updates. The thing is, by having the specific transactions of GnuCash be first class objects, this means that you get _considerable_ added robustness _without_ the DBMS being sophisticated at all. You soup things up again by having transactions _PLUS_ a robust, transaction-oriented database, and gets both more reliable, more powerful, and likely _quicker_. Virtually all the high-scoring TPC-D benchmarks on UNIX use BEA Tuxedo as a transaction processing layer sitting above Oracle. Apparently having a TP system manage transactions instead of Oracle improves performance, and the hardware folks like to see the combination make their hardware look good. The other "bonus" is that a suitably designed scheme can allow transactions to be created while the central DBMS isn't even running. Wrox Press has a book on the use of MSMQ/MTS which describes an example of how one might have remote sites have their own transaction managers that could queue transactions overnight and transmit to the central site when the connection comes back up. Another example of where this would be _really_ worthwhile would be when you have salescritters that run out to customer sites with laptops. With a transaction queueing system, they can transact the sales at the customer site, and then push the transactions on into the central system when they get back to the office. > Of course, like *any* front end based on *any* backend storage, you > still worry about your view being stale, e.g., my wife and I both > realize that $100,000 cash withdrawal is a typo and decide to correct > it. But I don't realize she already did it between the time I > retrieved my view and the time I decided to correct the entry. That > sort of situation will occur and just requires that the conflict be > detected and a sensible message returned. That's not entirely trivial to cope with, to be sure. -- [EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/lsf.html> Whatever is contradictory or paradoxical is called the back of God. His face, where all exists in perfect harmony, cannot be seen by man. _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
