Multi-Userness

[Christopher Browne]

On 17 Jul 2000 23:30:12 -0400, the world broke into rejoicing as
Roland Roberts <roberts@panix.com>  said:
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> >>>>> "jr" == Jason Rennie <jrennie@ai.mit.edu> writes:
> 
>     jr> Is GNUCash multi-user?  Won't different users store their
>     jr> accounts in different directories and hence separate styles in
>     jr> that way?  I guess a business setting is a place where many
>     jr> people may use and update the same account.
> 
> I'm hoping there will eventually be a backend which will allow a
> database to be plugged in for actual storage.  I'd like to be able to
> use gnucash while my wife also uses it.  This is one annoying thing
> about Quicken (so not only can I not use it simultaneously, but I
> can't use it when she's doing anything at all).

Another _interesting_ possibility...

I put together a CORBA-ized version of a single user application,
throwing in interfaces for the major data access bits of an API (it's an
example for a book; it will be GPLed, but you can't see it just yet...),
and more or less got multi-user access "for free."

By having data controlled in one server, it became _trivial_ to have a
whole bunch of clients connect to that server.

The way this might work with GnuCash would be for there to be IDL for
all the "public" stuff in ~/gnucash/src/engine, so that the GUI would
make requests for data via CORBA.  The engine would then be set up as
a daemon, and it's pretty easy for that to accept requests from a bunch
of Front Ends all at once.

Can it deadlock, and have other aspects of "bad performance"?  Surely.
Making "gnucashd" behave well with many clients would require that it
spawn a bunch of threads to service those clients.  But the _possibility_
of that does not prevent setting GnuCash up that way, and getting _some_
scalability.

In effect, in the absence of the use of threading, the server must
behave well in a model resembling Cooperative Multi Tasking, as opposed
to Preemptive MT.  So long as there are limits on how long any given
operation is allowed to "hog" the server, deadlocks shouldn't be _too_
much of a problem.

A way around this would be to have ONE process devoted to doing database
updates, which would receive updates, one at a time, that would thus be
rather limited in size/time expense, and then spawn, locally, a reader
process to support each user that would access data in a read-only manner.
That can scale pretty well even in the absence of threading (which is
tough to keep portable across platforms).

Note that restructuring the tasks and processes does not necessarily
require rearchitecting the code terribly much.  You don't NEED all
the bizarre services in order to get good milage out of restructuring
the application to make it scale better.
--
cbbrowne@acm.org - <http://www.ntlug.org/~cbbrowne/corba.html>
Error: Keyboard not attached. Press F1 to continue.