AppDomain - Exchanging data between host and child processes
-
I have a a problem that I haven't found found a solution for yet, so I'm turning to you guys. I need to execute an assembly in a new app domain in order to be able to completely garbage collect all resources that is used. The problem is that I need to return information to the host. How can this be accomplished? The reason I need to do this is that I'm using the Microsoft.Biztalk.Operations libraries to retrieve messages but (due to what I assume is a bug) sql connections used is not closed until the assembly is unloaded. Or is there any better way to do this? (GC.Collect does not close the sql connections) http://msdn.microsoft.com/en-us/library/microsoft.biztalk.operations.aspx[^]
-
I have a a problem that I haven't found found a solution for yet, so I'm turning to you guys. I need to execute an assembly in a new app domain in order to be able to completely garbage collect all resources that is used. The problem is that I need to return information to the host. How can this be accomplished? The reason I need to do this is that I'm using the Microsoft.Biztalk.Operations libraries to retrieve messages but (due to what I assume is a bug) sql connections used is not closed until the assembly is unloaded. Or is there any better way to do this? (GC.Collect does not close the sql connections) http://msdn.microsoft.com/en-us/library/microsoft.biztalk.operations.aspx[^]
Don't know about BizTalk, but normally sql connections are pooled so they are not actually closed, but only reset and returned to connection pool. However, the connection must be closed (in code) before the connection goes out of scope. Without closing the connection properly in .Net you may encounter odd behaviour (especialy with transactions). After closing the connection in .Net, if you take a look at database server, you can still see the connection (since it's open and in the pool). The connection is actually closed when it ages out of the pool. Mika
The need to optimize rises from a bad design
-
Don't know about BizTalk, but normally sql connections are pooled so they are not actually closed, but only reset and returned to connection pool. However, the connection must be closed (in code) before the connection goes out of scope. Without closing the connection properly in .Net you may encounter odd behaviour (especialy with transactions). After closing the connection in .Net, if you take a look at database server, you can still see the connection (since it's open and in the pool). The connection is actually closed when it ages out of the pool. Mika
The need to optimize rises from a bad design
Yeah, I know. The problem is that the connections is never re-used. If I retrieve 1000 biz talk messages, I get 1000 connections, if I wait a couple of seconds and retrieves the messages again, another 1000 connections will be created and this brings down the performance on the entire server. (vital in a production environment) and there is no way to close or reuse the connections in my code since they are created and used purely within Microsoft's own assemblies. I've tried to use a appdomain to read messages and this works great. The problem is how to return the data.
-
Yeah, I know. The problem is that the connections is never re-used. If I retrieve 1000 biz talk messages, I get 1000 connections, if I wait a couple of seconds and retrieves the messages again, another 1000 connections will be created and this brings down the performance on the entire server. (vital in a production environment) and there is no way to close or reuse the connections in my code since they are created and used purely within Microsoft's own assemblies. I've tried to use a appdomain to read messages and this works great. The problem is how to return the data.
That really sounds horrible! Since you must have some kind of mechanism to configure the connection string (or at least the elemental parts) could there be some kind of way to disable pooling if it's not used anyway (or even a way to get pooling working). If you have new connection for each message, the response time will be bad since getting the connection is very slow so this must be either bug or configuration mismatch. I cannot believe it's by design. If you cannot solve the problem that way, I believe you have following options (since different appdomains cannot share any info directly) - for example using wcf, create a service which is located in the appdomain that handles db. Define the info you need as out parameters in the service - communicate directly using IP (using for example loopback address) - use local db (or even file) to transfer data between domains - create a windows service that helps to return the data
The need to optimize rises from a bad design
-
I have a a problem that I haven't found found a solution for yet, so I'm turning to you guys. I need to execute an assembly in a new app domain in order to be able to completely garbage collect all resources that is used. The problem is that I need to return information to the host. How can this be accomplished? The reason I need to do this is that I'm using the Microsoft.Biztalk.Operations libraries to retrieve messages but (due to what I assume is a bug) sql connections used is not closed until the assembly is unloaded. Or is there any better way to do this? (GC.Collect does not close the sql connections) http://msdn.microsoft.com/en-us/library/microsoft.biztalk.operations.aspx[^]
Check you are disposing stuff that implements IDisposable. A bunch of APIs put IDisposable on relatively innocent looking stuff due to being thin wrappers for COM components (ie: GDI's Matrix class needs to be disposed - and thats really only be six bloody floats).
Mark Churchill Director, Dunn & Churchill Pty Ltd Free Download: Diamond Binding: The simple, powerful, reliable, and effective data layer toolkit for Visual Studio.
Alpha release: Entanglar: Transparant multiplayer framework for .Net games.