Jump to content

User.Config and Properties.Settings.Default.Save()


brewzer_bob

Recommended Posts

Someone please help me with this I am so about to blow my lid on this...I have a multithreaded application that uses a user.config file to store settings for each client...For example say I have 3 clients (A,B, and C) there will different data for each client, ID, Password, and a Reset boolean.I have a manager class that spawns a thread for each client in certain cases the client may need to set and save one of the values (say a password reset). My first pass was to call Properties.Settings.Default.Save() method after the value was reset, however I noticed that whatever was set first (say ID, then Password) only the ID (or first value) was getting saved in the user.config file, say I swapped them and set Password, then ID then only the password was getting saved... So I moved the "Save" method out of the getter and setter methods and it seemed to work... However when I try to save data for multiple clients this approach would only save the first client being set...So I then created an event in the Manager class that would be "bubbled" up by the "child" thread to the manager and save the values, this at first appeared to work fine as when the Application first starts it forces a run time password reset and all clients (A,B and C)'s data are being saved, however I also have a time interval (say after so many minutes) to reset the password again...The problem is once the values are save by the initial call(s) to Properties.Settings.Default.Save(), the subsequent call(s) (PER THREAD) are not being saved???Please anyone with any ideas please help... I am almost to the point of just treating this as a flat file and manually editing it like a raw .xml file...I can't find much info on this other than the basic examples...of like form size:Properties.Settings.default.myformpostion = "Blah";Properties.Settings.default.Save();...and that's all you need to do...well not true or am I missing something????Sorry to post this long A$$ message on here as it might not be the correct spot to post it but i'm cross eyed looking at this and reading on this and I wish I would have just stuck with a local xml (data) file and not messed with this whole config manger crap...yes I'm a bit frustrated....Thanks for anyone that can help me with this...

Link to comment
Share on other sites

Well it seems the only way to get around this was to iterate through each of clients in my user.config file and find the node I was trying to change again and issue a "save" on that node again. Seems the file get's disconnected somehow...I hope no has to struggle through this pain but prob shouldn't have been my approach for saving user data locally in a multi threaded app...I dunno...it works now...

Link to comment
Share on other sites

  • 3 years later...

That's C#, is it not?[Moving the topic to .NET]You'll need to lock the file as you modify it with each thread. That's how the concept of "critical resources" (and to be more precise, "mutex"-es) works. Lock right before opening the config file, and unlock right after saving it. Prepare yourself before the lock, and do the modifications you want during the lock, including the load and save, with as least statements as possible.During a lock, if another thread reaches a point where it too needs to lock the same resource, it will wait until the resource is unlocked. As soon as that happens, it will take the lock, and the same thing would repeat in case a third thread (or the former first) needs the same lock.The issues you're experiencing are exactly due to the lack of synchronization (otherwise achieved with mutexes over critical resources). Even if your app seems to work currently, it's fragile, i.e. there will be some cases, maybe only on some computers, where it won't work.

Link to comment
Share on other sites

That's C#, is it not?[Moving the topic to .NET]You'll need to lock the file as you modify it with each thread. That's how the concept of "critical resources" (and to be more precise, "mutex"-es) works. Lock right before opening the config file, and unlock right after saving it. Prepare yourself before the lock, and do the modifications you want during the lock, including the load and save, with as least statements as possible.During a lock, if another thread reaches a point where it too needs to lock the same resource, it will wait until the resource is unlocked. As soon as that happens, it will take the lock, and the same thing would repeat in case a third thread (or the former first) needs the same lock.The issues you're experiencing are exactly due to the lack of synchronization (otherwise achieved with mutexes over critical resources). Even if your app seems to work currently, it's fragile, i.e. there will be some cases, maybe only on some computers, where it won't work.
I recently experienced a problem like this. I had a proxy server running as a Windows Service that receives requests from multiple users on a machine and from other machines. I couldn't solve the problem of writing log files from multiple threads even with using mutexes or using the Synchronized TextWriters.I ended up writing a Queue that a write job would get added to and then the queue would iterate over it's jobs and write the logs every so often.
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...