It's been rumoured that Derek Atkins said:
>
> <[EMAIL PROTECTED]> writes:
>
> > I think I want to retract some of my comments. By default, when the gui
> > calls xaccTransRollback(), it will merely restore the data that was
> > previously cached in the engine. And should mostly be enough: its highly
> > unlikely that some other user changed the very same transaction, so its
> > a waste of bandwidth to have to double-check with the server.
>
> Ok, so the rollback method is just an 'unlock'. Ok.
Only if the begin method was a lock.
For the postgres backend, its all 'atomic': when the gui calls
xaccTransBeginEdit, its a no-op. When it calls xaccTransCommitEdit(),
it locks, writes data, unlocks. A deadlock can't happen, since a lock
is never held outside the scope of the backend. (i.e. all locks are
released before the backend returns to the engine/gui).
--linas
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
