Hello. I have a multi-threaded app that has a few different Timers all
of which deserialize and serialize objects to perform certain
operations. At the same time, the user can be working in the app and
making changes (thus deserializing and serializing objects, as well).
I'm sure you can see my problem.

Currently, I'm using binary serialization and hashtables to persist the
state of an entire form (including listview items/subitems, etc). It
works very well (a single call to DeSer or ReSer will save/restore an
entire form into a single file)... BUT... the problem is that,
theoretically, a thread can deserialize a form in the background while
the user is working with that same form, then the user exits (which
saves changes to a file) and then the background thread finishes, which
also saves changes to the same file, thus overwriting what the user
just did.

I'd really like to find a "smarter" way to handle persistence, so that
calling objects is just as easy, but also flexible and scalable.

Are there any better options to do this? I've heard about DB
persistence, but I don't know much about it and I'm not sure of the
implications: Wouldn't the data provider I use need to be present on
any client machine where my app is installed? Would this require
mapping my entire app to a database? etc. etc.


I'm just looking for some feedback on this. Any help is appreciated.


WATYF

Why is the thread deserialising a form?


"WATYF" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hello. I have a multi-threaded app that has a few different Timers all
> of which deserialize and serialize objects to perform certain
> operations. At the same time, the user can be working in the app and
> making changes (thus deserializing and serializing objects, as well).
> I'm sure you can see my problem.
>
> Currently, I'm using binary serialization and hashtables to persist the
> state of an entire form (including listview items/subitems, etc). It
> works very well (a single call to DeSer or ReSer will save/restore an
> entire form into a single file)... BUT... the problem is that,
> theoretically, a thread can deserialize a form in the background while
> the user is working with that same form, then the user exits (which
> saves changes to a file) and then the background thread finishes, which
> also saves changes to the same file, thus overwriting what the user
> just did.
>
> I'd really like to find a "smarter" way to handle persistence, so that
> calling objects is just as easy, but also flexible and scalable.
>
> Are there any better options to do this? I've heard about DB
> persistence, but I don't know much about it and I'm not sure of the
> implications: Wouldn't the data provider I use need to be present on
> any client machine where my app is installed? Would this require
> mapping my entire app to a database? etc. etc.
>
>
> I'm just looking for some feedback on this. Any help is appreciated.
>
>
> WATYF
>

A few of the forms contain listviews which hold items that specify when
certain things will happen, or what operations will be perforned... so
the Timer event will open the form, loop through the items in the
listview, and see if any of the items in it need to be run... if so, it
runs them... when it's done, it updates the items in the listview with
new information and reserializes the form so that the next time the
user opens the form, they will see the updated items in the listview.

WATYF