So you are suggesting a flag-on-commit? The problem with CVS is that
before you can commit you have to 'update' yourself and then, as a
user, you have to clear any conflicts before you can actually commit.
With an active repository with many users this is obviously a highly
iterative process. I've heard lots of users grumble about this.
OTOH, you're right. I wouldn't want to be locked out of an account
because someone else didn't close their windows when they went to
lunch.
Perhaps we need a more distributed-data model? Whenever you have an
account 'open', you register a callback with the 'data store'. Then,
whenever someone modifies the data store you get called back and
notified of the change. Then the GUI can either flag the user in
real-time or, if there isn't a conflict, possibly just update itself
behind the user.
This still leads to race conditions, but it means you only need to
lock the account during an actual commit (which is probably a good
idea). This would imply a path that looks something like (let's assume
a race condition here):
User 1 Data Store User 2
<----------------- Pull Account Data ---------------->
(Register's CB)
[Change Data] [Change Data]
Lock Acct ------------->
<---------------------- Lock Acct
<--------------------- Acct Locked
Commit ---------------->
Callback ---------------------->
[ Notify user,
fix conflicts ]
<--------------------- Committed
Unlock Acct ------------>
<----------------------- ACK
Acct Locked ------------------->
<------------------------ Commit
<--------------------- Callback
Committed ----------------------->
<---------------------- Unlock Acct
ACK ------------------------->
There is still a problem if you have a non-conforming client
application that someone could screw up the model by performing a
commit on an unlocked account. Theoretically the Data Store could
verify that the account is locked and just return an error to the user
if it isn't. Also, it's still possible for a non-conforming
application to ignore the callback and still commit before conflicts
are fixed.
OTOH, I believe conflicts tend to be conflicts of balance, not
identical transactions. And I don't think we actually store a running
balance, do we? So, the case of the "ATM attack", the ATM would
actually want to check the callback to make sure the user has the
available balance as part of the commit. This would imply that the
client-imposed lock is a Good Thing. The ATM would lock the acct,
know that the balance is right, commit the txn, then unlock the acct.
Then the second ATM would lock the account, but it would have received
a callback before the lock succeeds, notifying it of the changed
account status.
How does this sound?
-derek
[EMAIL PROTECTED] writes:
>
> It's been rumoured that Christopher Browne said:
> >
> > On Sun, 26 Dec 1999 22:25:48 PST, the world broke into rejoicing as
> > Rob Walker <[EMAIL PROTECTED]> said:
> > >
> > > >>>>> On Sun, 26 Dec 1999 23:46:52 -0600, Christopher Browne
> > > >>>>> <[EMAIL PROTECTED]> said:
> > >
> > > Christopher> d) The other thing that would logically go along with
> > > Christopher> this would be to have some sort of "transaction lock"
> > > Christopher> scheme which would forbid two windows from modifying the
> > > Christopher> same transaction at the same time.
> > >
> > > why? whatever one was committed last would take precedence, no?
> >
> > One of the goals is to allow GnuCash to support having multiple users
> > working on things at once.
> >
> > And it's not acceptable to assume that they *know* they're trampling
> > on one another; it is better to tell at least one of them that they're
> > "trampling" and indicate that this isn't being permitted.
>
> There are situations where its even worse. The classic example:
> There's a bank account with $50 in it. Two users walk up to two ATM's
> at the same time, and access this account at the same time. Both see the
> $50 balance, and withdraw $50. At the end of the day, the recorded
> balance is ???
>
> Traditional solutions to this are to lock down the entire account.
> But I think there's a better way:
> Traditional source control systems (e.g. RCS, CMVC) lock down an entire
> file and let only one user edit it. But systems like CVS allow multiple
> writers to make simulataneous changes, and instead flag conflicts.
>
> I think something similar can be done for financial info when multiple
> users are accessing one account. This would avoid deadlocks/lockouts
> just because the accountant went out to lunch without closing all of
> thier windows.
>
> --linas
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
>
>
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH
[EMAIL PROTECTED] PGP key available
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
