Creo que el problema de nuestro amigo es precisamente el error de OutOfMemory, lo que indica que si que hay un problema en la liberación de memoria, debido probablemente a los que indica Francisco, hay objetos que se quedan referenciados y el GC no es capaz de liberar memoria cuando el sistema la necesita. Por eso creo que el problema está en la implementación del patrón de diseño, pero sin poder verlo es imposible detectar el error. Para nuestro amigo es indiferente si la memoria se libera instantáneamente o no, el problema está en que esta llega a saturarse por que NUNCA se está liberando.
El 23 de enero de 2009 10:12, Gustavo Ringel <[email protected]>escribió: > No necesariamente tambien puede ser unmnanaged objects que no se suprimen > de manera adecuada (connections a la database, etc) > Pero igual mi intencion no fue discutir contra lo que vos decias, sino > aclarar que la prueba de abrir objetos y hacerles dispose y esperar que la > memoria se libere de inmediato es un error conceptual. > > > Gustavo. > > 2009/1/23 Francisco A. Lozano <[email protected]> > >> >> No lo sabía, pero creo que ese hecho no es importante. El que haya una >> OutOfMemoryException indica que hay objetos que no han sido marcados >> para liberación (ya sea ésta al eliminar la referencia o al reclamarla >> el runtime para otras allocations). Por tanto, estos objetos siguen >> estando referenciados. >> >> Francisco A. Lozano >> >> >> >> 2009/1/23 Gustavo Ringel <[email protected]>: >> > Francisco por supuesto que tenes razon en un punto de vista teorico, >> pero en >> > la practica el GC de C# solo recolecta memoria cuando hace allocation. >> > >> > Ver por ejemplo esto: >> > >> http://blogs.msdn.com/tess/archive/2007/04/10/net-garbage-collector-popquiz-followup.aspx >> > >> > If we exclude GC.Collect calls, this means that a GC will only occur on >> > allocation. I have mentioned this before, but I think it is worth >> > mentioning again... a classic mistake to make is to run a stress test >> and >> > then come back 10 mins after the stress test and wonder why memory is >> not >> > being released. In other words, objects may well be ready to be >> released >> > but no allocations are made, meaning no GCs will occur, so memory usage >> will >> > stay flat. >> > >> > Gustavo. >> > >> > 2009/1/23 Francisco A. Lozano <[email protected]> >> > >> >> >> >> Si el GC no elimina esos objetos de la memoria es porque mantienes >> >> referencias a los mismos, simple y llanamente, por mucho dispose que >> >> hagas. >> >> >> >> Francisco A. Lozano >> >> >> >> >> >> >> >> 2009/1/23 Plugin <[email protected]>: >> >> > >> >> > Saludos a todos. >> >> > >> >> > En primer lugar debo agradeceros vuestra dedicación y consejo, que en >> >> > más de una situación delicada me han salvado. >> >> > >> >> > La cuestión que quiero plantear es la siguiente: >> >> > Hemos puesto en marcha una aplicación ASP.Net que emplea NHibernate. >> >> > >> >> > Para la gestión de las sesiones, hemos usado el "Command Pattern", de >> >> > forma que cada caso de uso >> >> > se enmarca en una apertura/cierre de sesión. (de forma similar a como >> >> > se hace en el Session per view ) >> >> > >> >> > Ahora bien. Lo que hemos observado es que al hacer un Close o un >> >> > Dispose de la sesión, el GC hace caso omiso, y la memoria no se está >> >> > recuperando, de modo que tras hacer uso varios usuarios de la >> >> > aplicación, se produce una OutOfMemoryException... >> >> > >> >> > He probado a hacer un test de stress haciendo apertura/cierre/dispose >> >> > de sesiones, recuperando un objeto, y he comprobado que >> efectivamente, >> >> > el uso de memoria crece, crece.... >> >> > >> >> > Dónde puede estar el problema? >> >> > Hay algo que no entendí bien? >> >> > >> >> > Un saludo. >> >> > > >> >> > >> >> >> >> >> > >> > >> > > >> > >> >> >> > > > > -- ================================= Sergio Castillo Checa --~--~---------~--~----~------------~-------~--~----~ Para escribir al Grupo, hágalo a esta dirección: [email protected] Para más, visite: http://groups.google.com/group/NHibernate-Hispano -~----------~----~----~----~------~----~------~--~---
