I've got an application (1) running on an SBC pumping data out over a System.Net.Sockets.Socket object about every 1/2 second. I've got another application (2) receiving that data. When the data comes in to app 2, the data is parsed and stored into an object and then an event is raised telling a form on app 2 that it can do a few things with that object (the one that holds the parsed data).
The event handler displays data to a window (which needs to be done immediately) of app 2 and also attempts to write the data to a database. Writing to the database might be a problem if there is some sort of connection issue, etc. I don't want to be held up in the event handler because the database access couldn't be performed. So I figured I could just open up another thread to do the database access. However I worry about threads stacking up that couldn't finish (suppose the db time out is 10 seconds - by the time a timeout error occurs, I might have 19 more writes pending on active threads). It seems like there ought to be a better way to do this - maybe something like starting a thread that lasts as long as the app does that is solely used for the database writing. It could know whether it is connected to the db or not and keep track of the writes it was supposed to do, etc. Is this a legitimate way to make this functionality? Is there a better way? (aside - this issue started with all the processing and db access in the socket data handler. I noticed that if something held up the writing to the db in app 2, it actually cause issues with app 1 not being able to pump out its data over the socket). Peter =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
