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