Memory leak actualizando Enterprise Library de la version 3.1 a 5.0

The english version of this article can be found HERE.


Recientemente he estado trabajando en la actualización de un proyecto de .Net 3.5 a .Net 4, y de paso hemos actualizado de usar la Enterprise Library de la versión 3.1 a 5.0 y empezar a utilizar Unity para la inyección de dependencias ya que no hay bloque para ello en la nueva entlib.

Durante la actualización tuve que aplicar algunos de nuestros cambios a medida a la librería, principalmente a los bloques de Caching y Data, sin muchos problemas ya que el código que necesitaba los cambios sigue siendo bastante similar.

Pero una vez comencé a probar la aplicación me di cuenta de que habiamos introducido un enorme Memory Leak. En principio no era obvió que es lo que estaba ocurriendo hasta que encontre una forma de reproducirlo consistentemente.

Using the profiler of my choice (YourKitProfiler, very nice tool indeed!) I found out that there were a nice leak of Unity objects. Monitoring were those objects were being created I ended up in the method we used to get a new database connection.

Empleando mi profiler preferido (YourKitProfiler, que es una herramienta bastante salada) encontré que el leak principal era de objetos Unity. Monitorizando donde se creaban esos objetos acabé llegando al método que empleamos para solicitar una nueva conexión a base de datos.

DatabaseProviderFactory factory = new DatabaseProviderFactory();  
SqlDatabase db = factory.CreateDefault() as SqlDatabase;  

Como puede verse nuestro uso de las "Provider Factories" no era el apropiado ya que no haciamos Dispose de los objetos una vez habiamos terminado con ellos y creabamos una nueva instancia cada vez que necesitábamos una conexión a base de datos.

Lo curioso es que el uso de Unity por parte de la nueva versión de la Enterprise Library esta produciendo un grafo de dependencias entre objetos más complejo del que se creataba hasta entonces, por lo que pese a que antes no existía el Leak ahora si no haces Dispose como se debe el Garbage Collector no es capaz de limpiar los objetos.

Arreglé el problema empleando una instancia estática del Provider, de forma que siempre usamos el mismo objeto cada vez que necesitamos la conexión de base de datos. Otra opción habría sido usar un bloque "Using" para ese trozo de código, pero ya es cuestión de cada uno.

Imagino que un problema similar se encontraría de usar de la misma forma cualquiera de los otros Provider Factories de la Enterprise Library, no solo con la de bases de datos. así que si encontráis cualquier memory leak en vuestra aplicación tras actualizar de la versión 3.1 aseguraros de que estais usándolos correctamente.

Actualizacion: parece que hacer dispose de tus providers no funciona. Cada vez que creas una instancia de uno el fichero de configuracion es procesado por Unity, creando un grafo de objetos que lo representa y que no parece que se "dispose" incluso cuando haces dispose del provider. Asi que intenta mantener el número de providers al mínimo necesario, usando por ejemplo singletons.