-
Notifications
You must be signed in to change notification settings - Fork 930
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Memory leak named parameter holds entity references #3030
Comments
Sounds correct. What should we do? |
Release the reference to the entity once the session is closed perhaps. |
We can store proxy in cache. |
Meaning, replace the entity instances we see in parameters with new uninitialized proxy instances? Those proxies would have to be detached from the session, otherwise uniqueness of entities residing inside the session would be violated. What should we do if proxies are not enabled? With composite key entities with their id not mapped as a component? (There are issues for proxifying them.) I wonder why we need them in the query cache in the first place. Would it not be possible to nullify the parameter value in the cache? |
Turns out we do not need them. Named parameters are generated during initial phase of linq translation (in the constructor of I've decided to fix it in 5.3.13 because part of the problem was introduced in #2365 ( |
Cache only required parts of NhLinqExpression in QueryExpressionPlan Fixes #3030
Fixed in #3144 (5.3.13) |
Investigating a memory leak in an app, it was evident that the NHibernate.Engine.Query.QueryPlanCache was holding on to references to entities via instances of NHibernate.Param.NamedParameter. This only happens if the linq query expression embeds the entity itself as a parameter.
Below is a complete example which demonstrates this behaviour, note that only the first time a unique query is used is the entity pinned, see
var first_reference_is_not_null = firstReference.Target;
:The text was updated successfully, but these errors were encountered: