Multi-Userness

[Christopher Browne]

On 18 Jul 2000 22:00:21 -0400, the world broke into rejoicing as
Roland Roberts <roberts@panix.com>  said:
> >>>>> "cbb" == Christopher Browne <cbbrowne@hex.net> 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.
--
cbbrowne@ntlug.org - <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.