Skip to main content


Showing posts from November, 2007

Pooling Wisely for Oracle Data Provider for .NET

Use the Decr Pool Size and Incr Pool Size properties wisely when you use ODP pooling. Decr Pool Size Controls the number of connections that are closed when an excessive amount of established connections are unused, and Incr Pool Size Controls the number of connections that are established when all the connections in the pool are used. When a connection pool is created, the connection-pooling service initially creates the number of connections defined by the Min Pool Size attribute of the ConnectionString, and then Incr/Decr pool size properties are used to maintain the connections pooled. The values for Incr/Decr pool size should be based on your Min Pool Size and Max Pool Size values. Eg: "User Id=scott;Password=tiger;Data Source=oracle; Min Pool Size=10; Max Pool Size=1200;Connection Lifetime=120;Connection Timeout=60; Incr Pool Size=10; Decr Pool Size=5";

XmlSerializer Worries and Generating Typed Serializers

The simple constructors of XMLSerializer class caches the typed serializer once it is generated. When you use XmlSeializer to serialize a type, XmlSerializer will create a dynamic assembly on the fly containing the serialization code. When XmlSerializer is invoked from your application, The XmlSerializer constructor will reflect the type you are passing to the XmlSerializer constructor, and generate the code for typed serializer for the same.The code is compiled by calling csc at run timeThe resulting assembly is loaded to the application domain, and is cached for future uses.How ever, there is a known problem with XmlSerializer - some XMLSerializer constructors (other than the simple constructors) will regenerate the typed serializer assembly each time, instead of getting it back from the cache. In other words, XmlSerializer is not using the caching mechanism in every constructor - but only for simple constructors.Anyway, it is a better practice to generate your serializers at compi…

Unloading assembly from the Appdomain

It is pretty sad that Microsoft is not providing an ideal way to unload individual assemblies from an application domain :(
Right now, if you want to unload individual assemblies, you have to create another app domain, and then load your assemblies to that, and unload the entire app domain once you are done. But this approach has few problems If you are loading your assembly to a separate application domain, you have to use remoting for cros app domain callsYou don't really need a separate app domain to load and unload assemblies - because of performance reasons.I've read an interesting blog entry from Jason Zanders here