Access Controls

[linas@linas.org]

It's been rumoured that David Merrill said:
> 
> On Fri, Dec 29, 2000 at 02:46:51AM -0600, linas@linas.org wrote:
> > It's been rumoured that cbbrowne@ntlug.org 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