views:

84

answers:

2

In an application I'm creating, I've got two components that I want the user to be able to pause/resume. I'm wondering what standard patterns might exist to support pausing and resuming, if any? Both components do a lot of network I/O. It seems like, at a high level, I have to persist the current queue of work that each component has - but persisting it is where I'm looking for these standard patterns? Do I serialize the component itself? Do I serialize just the work? What format do I serialize to (xml, database, etc...)? What does .NET have built in that might help? Are there any libraries to help with this? Are there any differences to consider if the user just pauses/resumes within the same app session or if they pause/resume after opening, closing and then opening the application again? What about persisting this information across different computers?

Any suggestions from past experience or patterns that come to mind? I hope this turns into more of discussion of the various ways of doing this and the pros/cons of each. Thanks.

A: 

You could implement threading and simply call the Suspend() and the Resume() functions on the thread accordingly.

Gnostus
Those methods are both depreciated and that won't work across application sessions (e.g. open app, start work, pause work, close app, open app, resume).
Chad
In addition to Chad's comments, the Suspend and Resume methods are a very bad idea because they won't play nice with network I/O. You don't just want to pause, you want to pause at the correct point in the protocol sequence, and maintain any keep-alives, if necessary.
Kennet Belenky
I see, http://stackoverflow.com/questions/142826/is-there-a-way-to-indefinitely-pause-a-thread may shed some light.
Gnostus
+1  A: 

By message queue I meant MSMQ or one of it's brethren. All messages would be persisted in some sort of database and therefore still available when the app restarts. The primary purpose of such queues is to ensure that messages get delivered even when communication is intermittent and/or unreliable.

It sounds like you could have your communication components take work from MSMQ instead of your current queues pretty easily.

If that doesn't fit your application, it is probably as simple as serializing the objects in your existing queues on termination, and de-serializing them again at application start up. If surviving unexpected termination is important you should always serialize an object as it is added to the work queue, but at that point you may want to look again at an existing message queue system.

ScottS
Thanks Scott! It looks like MSMQ will take care of my needs.
Chad