On Fri, Dec 29, 2000 at 11:38:40AM -0600, [EMAIL PROTECTED] wrote:
> It's been rumoured that David Merrill said:
> >
> > On Fri, Dec 29, 2000 at 02:46:51AM -0600, [EMAIL PROTECTED] wrote:
> > > It's been rumoured that [EMAIL PROTECTED] said:
> > > >
> > > > It should be clear why Transaction engine and DB engine should stay close;
> > > > they will need to communicate quite a lot of data in order to negotiate
> > > > the parts that are to be submitted to the GUI. A "for instance" would
> > > > be that if the DB does not support computing sums/balances internally,
> > > > the transaction engine will need to do so, and will have to talk heavily
> > > > with DB.
> > >
> > > I had always hoped/envisioned that the engine could run both in the server
> > > *and* the client. In the client, it provides a convenient programming
> > > API, and a data cache. In the server, it provides transactional
> > > capabilities & functions (and a convenient programng API).
> >
> > What exactly is this "transaction engine"? All transactions can be
> > handled, and should be handled, within the db itself. The engine will
> > need to be aware of this functionality, but it needn't do anything to
> > make it happen. Any other approach is a mistake and a recipe for
> > disaster.
>
>
> What I meant was that there are several opportunities in the engine to
> hook in a locking mechanism: viz: the Begin() ad End() constructs.
> So the engine is aleady 'transactional', although the semantics
> are, um, 'malleable' (and that's not a bad thing).
>
> If you think of the gnucash engine on the client/GUI side, then the
> xaccTrasactionCommit()/xaccTransactionRollback() subroutines provide
> a handy mechanism for the GUI to support 'single-level undo'.
> >From that point of view, these functions are nothing more than that.
>
> If you think about it from the server side, then BeginEdit() is
> a great place to grab a lock, and End() to release it. Any other
> users attempting to Begin() on the same transaction need to be
> held off or otherwise dealt with.
I don't think it's wise to have the client telling the db when to set
and release locks. Rather, all the data required to perform a
transaction (which in this context I consider just a set of updates,
like saving a transaction along with all attendant splits) should be
sent as one "packet" to the db, which attempts the save and reports
success or failure.
OH, I think I just realized I'm misunderstanding you. Do you mean to
set a "lock" (not a real DB lock though, or at least not necessarily a
real DB lock) when the user BEGINS to do an edit, so other users
cannot? Now THAT makes sense. :-)
I would not establish a real DB lock in this situation because it
really screws with your db concurrency. Instead, perhaps some kind of
status field in the db to indicate that the record is "checked out" by
a user would work better. Or, even more improved would be a field
where you put the userid of the user who is editing the record.
> If you think about it as a transport mechanism, then Begin(), End()
> are the *only* times a message needs to be sent from client to server.
> After a session has been intiated, *none* of the other API calls should
> generate traffic.
Now you lost me. ???
> The implementation I would prefer for all of this is to have it
> all work in a CVS-like manner. Viz, multiple users can edit the
> same transaction, but when they 'cvs commit', only one can win.
> The others loose; they must 'cvs update', fix any conflicts, and
> try 'cvs commit' again until they win, or until they get bored.
Yes, I am trying to do it this way if I can. It is decidedly
nontrivial and may not make it into the first release. I am already
becoming rather ruthless about cutting things.
I *do* keep a complete auditing trail, so changes *can* be reversed.
> The reason I like CVS-like semantics is because it has very very low
> lock contention, because the locks are held only for the shortest
> of intervals.
>
> BTW, is there a Formal Academic Name for 'CVS-like semantics'?
Yes, but it escapes me atm. I promptly flushed my neural net of all
that upon graduation.
--
Dr. David C. Merrill http://www.lupercalia.net
Linux Documentation Project [EMAIL PROTECTED]
Collection Editor & Coordinator http://www.linuxdoc.org
Finger me for my public key
Under the full moon light we dance
Spirits dance, we dance
Joining hands, we dance
Joining souls rejoice!
-- Karen Beth
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
