This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I've noticed that my application consumes more and more memory. Using CLRProfiler (http://www.microsoft.com/download/en/details.aspx?id=16273) I've checked that the whole bunch of data objects is held by Lightspeed, despite I've nulled all Context and UnitOfWork objects (and called GC.Collect() afterwards). It looks like my UnitOfWork is held by Mindscape.Lightspeed.Querying.Query, which is held by Mindscape.Lightspeed.Model.TypeModel. I have no access to this class and I don't what what it exactly does - to me it looks like a 'static' class which holds field getters and setters. Anyway - I cannot reproduce similar error on a simple example. Please let me know if it is possible that TypeModel holds Queries and doesn't detach them after all contexts and UOWs are nulled? Can I somehow detach them / clear cache / do anything else to get the memory freed? I'm currently using 20111201 nightly. |
|
|
|
|
TypeModel is an internal class which is used to hold information about the structure of an entity such as what value fields are being tracked by LightSpeed. The information held by the TypeModel instances are largely the same as the information exposed through the MetaData API. TypeModel is fairly extensively used internally whenever we look up information about an entity, but a TypeModel instance wont be holding any references back to a Query. It would be used by a query, so the reverse would be true. I am curious about what you are seeing. Are you holding on to your query objects in your code, or do these get disposed or fall out of scope? And also when you "nulled all Context and UnitOfWork" objects, did you do this by nulling the UnitOfWork property on your entities (or alternatively detaching them) or did you do this by nulling out the UnitOfWork instance directly in your application code?
|
|
|
|
|
I'm disposing UOW's by calling uow.Dispose() and assigning 'null' to the field which holds reference. For context objects I'm assigning 'null' to the field which holds reference. So there's no automatic falling out of scope. I've prepared a screenshot from CLRProfiler, which shows who holds which objects - please see the attached file. On the screenshot I've marked objects of interest in this particular situation. Below you can see details generated by CLRProfiler for each one: As you may see, there's only one reference to my UOW (Object 4) and it comes from Query (Object 3). This Query has only one reference from unknown object (Object 2), which is held by TypeModel (Object 1). The values in kB or MB show total memory held by a particular reference (not only a single object itself). They come from a relatively small example. For a large example I have a 200MB leak, which I cannot forget. Please help me finding a solution to this problem. I have a log file saved by CLRProfiler, which I could send to you, but it's too large to upload as a post attachment (6MB packed). Using this file you could see the graphs and get the same information which I posted above. |
|
|
|
|
I found a possibility to generate an allocation graph - it means a call stack of methods which led to creation of a particular object - please see the attached picture. On this graph you can see that the Query (Object 3) was created by GetFindByIdCompiledQuery. Maybe these compiled queries are somehow cached/stored and they are responsible of my memory leak? For a better understanding - getStrefaTemperaturowa is an automatically generated code by LightSpeed of 1to_N relation (N "Mieszkanie"s in 1 "StrefaTemperaturowa"). |
|
|
|
|
Thanks for the additional info. Compiled queries do hold on to a copy of a query object to use as a template for any subsequent calls, saving on the cost of regenerating the query. CompiledQuery instances for FindById will be used in preference to generating a new query object each time they are used so they will be generated automatically within LightSpeed as needed. They should only be scoped as long as the TypeModel instance is available, but if those objects are hanging around for a while then the compiled queries and query objects could also remain in memory which could explain the leak you are seeing. I am not sure how that would occur however so I wil have a look and see if I can set up some test cases here to try and reproduce the leak and I will update you once I have made some progress with this. If you have any more discoveries please let me know :)
|
|
|
|
|
I have browsed the type Mindscape.LightSpeed.Model.TypeModel in the Watch window of VS. Inside I found " Maybe you could simply make a public static method, which iterates through all type models and sets 'null' to '_findByIdCompiledQuery'? Of course a better solution would be if UnitOfWork in its "Dispose()" method deleted all references to itself (in queries referenced by TypeModel dictionary). |
|
|
|
|
Thanks for drawing our attention to this. It will be fixed in the next nightly build -- let us know if you still see the issue. |
|
|
|
|
It looks like the problem is gone on the latest nigthly :-) Thank you. |
|
|
|
