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
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user
