[Gambas-user] Concurrent gb.settings

[Tobias Boege]

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