Ambiguity in file handling from Digest, Vol 157, Issue 23

[Colin Law]

On 14 April 2016 at 13:27, John Angelico <talldad at kepl.com.au> wrote:
> On 14/04/16 21:56, gnucash-user-request at gnucash.org wrote:
>>
>> No, though I see a possible ambiguity.
>>
>>> >
>>> >First, "As Colin already writes" the database backend will write each
>>> > change
>>> >immediately, not at the end of the session.
>>> >
>>> >Then "the other part of Colin's reply is also correct" gnucash reads the
>>> >entire database into memory, and works there until the end of the
>>> > session,
>>> >leading to the risk of data conflicts and corruption.
>>
>> Gnucash does work in memory*and*  it writes out changes to the db as
>> they are entered.  The working is still in memory.  The key point is
>> that it does not see any changes made by other users (if that were
>> allowed), which could mean that the changes it later writes back could
>> make the db inconsistent.
>>
>>> >
>>> >Is there already a difference between the file handling under XML vs
>>> > SQL?
>>
>> Yes, as described, when it comes to the saving algorithm
>>
>> Colin
>>
>
> Thanks Colin.
>
> Ambiguity resolved, but the risk of data corruption or loss by overwriting
> should only occur if multiple users of one set of data files forget that
> fact.
>
> So when GC asks later users to confirm opening the files despite the lock
> file being in place, they respond incorrectly to open them for writing
> anyway. Thus the problem is one of user discipline.

Yes, obviously.  However we have here been discussing the merits of
using the DB backend, and until full db support becomes available
there is very little advantage, and there is the potential
disadvantage that if two users do make changes at the same time it
could make the database unusable, whereas with xml the worst that
happens is that changes are lost.

>
> However, it remains true that if GC used a DB backend with the relevant
> features, data clashes could be reduced or eliminated.

I believe this is the long term aim of the developers, to allow full
multi user access, but it is a great deal of work I believe.

Colin