Thank you Barry, Phil, and Peter. I'm working on implementing this separate thread processing now. I'll let you know how it goes.
FWIW, app1 is pushing a string of data about 1024 bytes long every half second for up to an hour. App1 runs on a system with no keyboard/mouse/monitor so it needs to not 'fail' during this operation - especially due to something that is really app2's fault. Peter -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Barry Kelly Sent: Wednesday, March 26, 2008 2:15 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] threads, sockets, db writing Peter Osucha <[EMAIL PROTECTED]> wrote: > 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? This is a basic producer-consumer queue. There must be hundreds of example implementations out on the net. > (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). Of course. Bear in mind, you may want this behaviour in certain cases: if the data is coming in faster than it's being drained from your queue, and you don't block so that the sender is forced to wait, you can eventually end up running out of memory. Actually, the problems can start earlier than that: without request throttling, you can cross a thrashing threshold, where even if the requests back off, the queue fails to clear fast enough because of e.g. VM paging. -- Barry -- http://barrkel.blogspot.com/ =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
