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.
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.
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.
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'?
--linas
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
