[Gambas-user] Concurrent gb.settings

[PICCORO McKAY Lenz]

This is a old mail, but interested me, that i try to make some kind of
framework for my apps..

what the status of that problem Tobias? see below the message:

2016-02-12 7:55 GMT-04:30 Tobias Boege <taboege at gmail.com>:

> Hi Benoit,
>
> in my project I use a Gambas library which manages some kind of flat file
> database where "config" files in gb.settings format play a role. The
> current
> project I use the library in is a gb.web.form project. I got to install it
> on a friend's server and on its first day of runtime, I noticed that the
> config files got corrupted: either the whole file or some lines of them
> vanished.
>
> I suspect that this is due to the library saving the configs on exit.
> Naturally the gb.web.form project initialises and exits very often and
> concurrently. I must add that the project only reads the database and does
> not modify it, so the writing is useless. And indeed after I modified the
> library to not issue explicit Settings.Save()'s and refuse to modify any
> value in a Settings object (which would trigger the auto-save mechanism in
> gb.settings), the server ran for 34 hours now without a problem.
>
> Clearly I'm at fault for the file corruption here, but does this problem
> not
> sound common enough to deserve some thought about a solution inside of
> gb.settings?
>
> I could imagine a Settings.ReadOnly property which when set to True
> disables
> the automatic saving of configuration files in Settings._free() (and maybe
> cancels even explicit Settings.Save()s). That's the pattern I now have in
> my
> library, to restrict access to Settings methods.
>
> There are two things that puzzle me though:
>   1. Apparently gb.settings already uses lock files to counter this sort of
>      corruption. What happened?[*]
>   2. How could sometimes a whole config file vanish, i.e. it is not only
>      emptied but does not exist anymore in the filesystem.
>
> If you have no idea, maybe I can reproduce the issue... [ JFTR: whenever it
> happened that a part of a web page, like a background image, could not be
> loaded, it was an indicator that a config corruption happened. Probably the
> server crashed in an unhandled error (from Settings.Save()) before the file
> was sent. So even if I can't reproduce it, I might still verify that it is
> gb.settings. ]
>
> Sorry for the long mail. Some passages are just reminders for myself :-)
>
> Regards,
> Tobi
>
> [*] Maybe this theory makes sense: imagine three processes are trying to
>     write the settings concurrently.
>
>     The #1 gets the lock and begins writing. Now #2 kicks in and fails to
>     get the lock. In the Finally block in Settings.Save(), it Kills #1's
>     lock file (is that possible if #1 still holds the lock?). Then #3 can
>     acquire the lock again and writes concurrently with #1.
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
> <https://lists.sourceforge.net/lists/listinfo/gambas-user>


Seems the problem it's when more than a process write same file, using
locks!?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180429/5d840e97/attachment-0001.html>