We need to prevent multi-user access to the SQL backend (Re: New GnuCash article on LWN)
Graham Leggett
minfrin at sharp.fm
Sun May 23 08:10:17 EDT 2010
On 21 May 2010, at 6:04 PM, Derek Atkins wrote:
>> Because a situation arises when both of you need to make writes.
>> Which
>> copy is the authoritative copy? Using svn alleviates this somewhat,
>> but isn't ideal.
>
> The authoritative copy belongs to whomever has the "write token".
Otherwise known as the "svn lock".
Sharing access is a lot simpler than people think. It is not strictly
necessary for gnucash instance A to be 100% up to date with gnucash
instance B.
The only time it does need to be up to date is when an amendment is
made to a transaction, and at that point you construct the update
query in that it replaces what gnucash instance A believes was the
previous version of the transaction. If the query was successful,
we're done. If the query touched no rows, we know there was a
conflict, and the user will need to be asked to make their amendment
again, resolving the conflict.
To keep registers up to date, keep a table containing a "last updated"
timestamp on each account. The timestamp's value isn't important, only
that it has changed. Instance A and instance B polls the table from
time to time, and reloads any register as necessary.
Regards,
Graham
--
More information about the gnucash-devel
mailing list