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 time
• The 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 compile time, instead of using XmlSerializer which effects in run time generation of typed serializers. Atleast, this will definitely improve your application performance during startup (for web applications). For desktop applications, you should use typed serializers.

You can use some typed serializer generators like SGen or Mvp.Xml.XGen to generate typed serializers. SGen is not very mature, because it fails to handle a couple of scenarios, and may skip some types with out any warning.

Mvp.Xml.XGen is better.What it does is, pass the type to generate the code to XmlSerializer at design time itself, and then stealing away the code generated by XmlSerializer (and optimize it a little bit), to compile the typed serializer code - and provide you the typed serializer at design time itself.

When you pass a type to XmlSerializer, the code generated can be fetched from the temp folder, provided you requested XmlSerializer constructor not to cleanup the code it has generated. For this, you've to add a hidden switch to your application config file - like

<configuration> <system.diagnostics> <switches> <add name="XmlSerialization.Compilation" value="4"/> </switches> </system.diagnostics> </configuration>

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 calls
• You 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