In the DAL, we create sessions and close sessions immediately when we: get data, insert data, update data, or delete data. We create longer running sessions for transactions that end with a commit or a rollback. Otherwise, the sessions are closed. I tried GC.Collect() immediately after BuildSessionFactory() and there was maybe a one meg change. Nothing much. As for our product, it stems from a legacy DOS application so most design decisions were made on that a long time ago, including architecture. We use a wide array of methods of sharing info between processes on the same machine and separate machines (WM_* messages, MSMQ, etc) but generally each application acts independently of each other. Ideally in the long term they would slowly merge into a common business layer, and that's what we are working towards, along with a new common DAL. Just the DAL is causing us issues right now. :)
Thanks again. On May 16, 1:04 pm, Ramon Smits <[email protected]> wrote: > On Mon, May 16, 2011 at 5:44 PM, Kyle <[email protected]> wrote: > > Unfortunately it is a legacy application with a legacy database that > > we do not have the time to rework. No greenfield work here. :( I > > agree it is a large waste of resources, but it is what it is. I'm > > actually not doing any loading of data at this point. Everything is > > setup to be lazy from what I understand, even the domain objects. > > > This call is where memory goes from ~18 MB to ~165 MB: > > sessionFactory = configuration.BuildSessionFactory(); > > > I do keep the session open for an application/process right now. How > > can I guarantee that everything is lazy loaded? > > All relationship mappings in NHibernate are lazy by default but a lot of > beginners think lazy is slower and make them non lazy resulting in fetching > a whole aggregate or sometimes even all database data when they just wanted > to select one record. > > You should close the session when you can. You should have a session per > unit of work. Then when you want to do something again you should create a > new session. You should create a session factory once and reuse that all the > time. Creating sessions is *very* cheap. > > When you have created the session factory you mention that the process is > occupying 140mb. Is that the memory you see in the task manager? Because > .net is managed it will not release memory immediately. You could try to > create the session factory and then let the garbage collector free memory by > calling GC.Collect(). Only do this for testing purpose! Then please report > the memory is actually still using after initialization. > > By the way, just out of curiosity, why do you spawn all those processes? Do > all these processes run under different credentials? What is the reason for > this design. How do you communicate with all these processes? Via WCF, .net > remoting, sockets? What do you use? > > -- > Ramon -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
