1

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.

H H
  • 263,252
  • 30
  • 330
  • 514
Chad
  • 3,159
  • 4
  • 33
  • 43
  • Are you just pausing communication between components, and the "work" will continue to accumulate, or does the work get paused too? It definetly makes a difference if the paused work needs to survive termination of the application. A message queue will allow you to accumulate work (messages) without risk of losing it appilcation is terminated, but may be a heavier solution than required. – ScottS Jun 17 '10 at 18:09
  • Scott - No, work will not accumulate when the app is paused. Can you explain how a message queue will survive if the app is terminated? Maybe provide more details on this message queue structure you're referring to? Both of my components already have work queues, but they wouldn't survive if the app was closed. Thanks. – Chad Jun 17 '10 at 18:14

2 Answers2

1

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
  • 8,455
  • 3
  • 30
  • 50
-1

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

Jake Kalstad
  • 2,045
  • 14
  • 20
  • 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 Jun 17 '10 at 18:08
  • 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 Jun 17 '10 at 18:20
  • I see, http://stackoverflow.com/questions/142826/is-there-a-way-to-indefinitely-pause-a-thread may shed some light. – Jake Kalstad Jun 17 '10 at 18:20