[fpc-devel] Rather large flaw in TJSONConfig component

Henry Vermaak henry.vermaak at gmail.com
Mon Jun 21 15:34:14 CEST 2010


On 21 June 2010 14:20, Graeme Geldenhuys <graemeg.lists at gmail.com> wrote:
> Hi,
>
> Attached is a patch which extents the jsonconf test suite. The new test
> highlights a rather big flaw in the workings of the TJSONConfig component.
> This issue might even apply to TXMLConfig component too - I haven't looked yet.
>
> This came about in the discussion in the Lazarus mailing list about Lazarus
> IDE storing application settings in XML files. I investigated the idea of
> replacing my usage of INI files for storing application settings with JSON
> files (TJSONConfig) instead. In each of my applications, I store all GUI
> Form state (position, size, etc) all in one "application settings" file -
> each form has it's own XXXFormState section.
>
> In the test TestConcurrency I simulate two forms being opened - each form
> contains a TJSONConfig component. When I close one form it writes the state
> information. When I close the second form, it overwrites the whole JSON
> file, wiping out the first form's information completely. This is rather
> dangerous behaviour!
>
> I see 3 solutions here:
>
> 1) Use a Singleton with TJSONConfig so we only have one instance of
>   TJSONConfig per application.
> 2) Extend TJSONConfig so that it is more intelligent when writing to
>   a file, and only writes the path information it modified or created.
> 3) When using one TJSONConfig per form, force the developer to use
>   a different .json file for each form.
>
>
> Any comments or alternative solutions?  I know XMLConfig and JSONConfig are
> not documented yet, but if nothing is going to be done about this
> concurrency issue I highlighted, then the documentation must clearly state
> the dangerous behaviour of these components.

Seriously, would you try the same thing with a file?  Open it in two
different places and try and write to it from both places and see what
happens.  Programs that want to write to the same json file from
different classes need to handle this properly, just like they would
have to when using files.  The behaviour is completely logical, imho.

Henry



More information about the fpc-devel mailing list