On 31 Dec 1999 11:06:06 EST, the world broke into rejoicing as
Derek Atkins <[EMAIL PROTECTED]> said:
> Christopher Browne <[EMAIL PROTECTED]> writes:
>
> > The example I'm thinking of is one that *can't* occur right now.
> >
> > Consider having two users adding/modifying data in the "Cash"
> > account.
> >
> > They are asynchronously adding/changing data, and this could lead to
> > their respective register views being a bit out of data.
> >
> > User A might have gone for coffee break, and there have been *no*
> > events. Ergo, the 8 transactions that User B entered during that time
> > aren't on A's screen.
>
> Um, I think you're a bit confused, Chris. Those 8 transactions
> entered (and committed) by user B would imply 8 events received by
> User A... For each new transaction entered by any user, all users
> receive an event from the engine. So, while user A was gone for
> coffee break, their display would get updated by the events from user
> B's new transactions.
The display might not update until the user does something that results
in pulling those events, but that's certanly "close enough."
I wasn't assuming the existence of a distributed "Event Service;" that's
where the scenario above would come from.
If there's a concrete plan to have a network-aware event service, that
handles this "discrepancy."
> > They're in the database, and even if A's view of the data is a bit off
> > right now, this *probably* isn't causing any big problem. If he adds
> > in another 10 transactions, even if he hasn't seen B's work, A's
> > transactions are probably also fine.
> >
> > Eventually, they'll reopen the register, and get fresh views that will
> > contain both sets of work.
> >
> > The balances that they see might be off, which is the "problem" that I
> > was alluding to; if all the data that has been committed is correct,
> > and reports are correct, then the fact that there is a temporary
> > discrepancy doesn't seem overly worrysome to me.
> >
> > I'm worrying about what is, effectively, a pretty obscure point that
> > still leaves the transactions correct. So it's not a real big worry.
>
> If you have events, as I described, then this isn't a problem because
> the display would get updated in "real time."
Fair enough.
It's worth noting that a distributed transaction locking scheme is
quite similar to an event service, and this is suggestive that fixing
one of the anomalies may make it "obvious" to fix 'em all.
--
Rules of the Evil Overlord #79. "Bulk trash will be disposed of in
incinerators, not compactors. And they will be kept hot, with none of
that nonsense about flames going through accessible tunnels at
predictable intervals."
<http://www.eviloverlord.com/lists/overlord.html>
[EMAIL PROTECTED] - <http://www.hex.net/~cbbrowne/lsf.html>
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
