I think that if you don't specify that the message should be recoverable, the default is to keep the message in memory.
-----Original Message----- From: Moderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 10:01 PM To: [EMAIL PROTECTED] Subject: [ADVANCED-DOTNET] Shared Memory Implementation? I have an asynchronous class for doing DB updates and inserts. The client passes the data to a queued component, the work gets done, and the QC puts the result into another Message Queue. The client repeatedly checks the Message Queue for a result at will (a web page simply refreshes saying "checking" ... "checking" until a result is found in the queue or the web user gives up or 10 retries). I was thinking about the slowest part of the app and it appears to be the disk-bound MSMQ. Can anyone recommend a shared memory implementation or "memory queue" I could use to hold this async-worker result messages? While I think the return messages would be in the area of 1k, for the sake of argument let's say it could be 16k and there could be a few hundred of these in memory at any given time. I'm willing to forego the guaranteed delivery/safety of MSMQ for speed in this case. Plus I want to learn how it would/could be done. :) Where could I look into that kind of thing for the .NET Framework? Thanks.
