Looks like Peter beat me to it this is basically the same with a little more "flesh".
If you are concerned about db connection & write issues...I'd suggest looking at Messaging with a local queue. the sequence of processing would look like this. [1]app2 receives data [2]app2 creates object out of incoming data stream and drops it in the local queue. app2 has a separate thread running that monitors the queue (polling every "x" seconds, or listening for events). when the thread notices a new item in the queue... [1]pull the object off the queue [2]hand it off to a unit-of-work object. [3]call a "ProcessTheObject" method on said "UoW" object. [4]the unit of work object will do the database work for you. and return success or fail. on failure, put the object back in the queue and find a way to notify the user of the problem. this allows the Messaging queue to continue to fill up with the data that comes into app2, once the database connection is fixed/resolved the items in the queue can be processed again, and you habven't lost anything. an alternative is something like....use a local DB ... MSAccess or sqlexpress (thta way you remove the network as a potential failure point)... and use the "replication" functionality provided by sqlserver to take care of the "move the data to the main sql server" piece of the puzzle. I'm pretty sure sql supports a "sometimes connected" model of keeping things in synch. You may also be able to use queues to communicate between applications instead of sockets. -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] Behalf Of Peter Osucha Sent: Wednesday, March 26, 2008 1:56 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: [ADVANCED-DOTNET] threads, sockets, db writing 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 =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
