This question is locked. New answers and comments are not allowed.
I am using DataAcces ORM on asp.net application and I would like to know if there is connection between the DataAccesContext and the objects retrevied via Linq or low ADO.NET Api, regarding disposing the context? As I have observed, I have a list of object that is used inside a datagrid and after disposing the context, in the profiler I don't see any change.
I read the documentation regarding the usage of DataAccess inside an ASP.NET application but my case is rather special because I use Visual Web Gui, which acts as WinForms inside the asp.net, so the only real possible solutions that I have are either disposing the context after any CRUD operation(and somehow don't use the objects that were maintained by that context either by using DTO template, or using detaching, in these cases I had some experiences in the past about performance penalty and are not option), or disposing the context after the form was closed, which brought me to the question that I asked in the beginning in my post.
So to summarizes this up I would like to know:
1.What is the correct way of disposing the context and without any memory leaks?
2.What is the best settings that I would have to make on the IIS part ,regarding application pool?
I read the documentation regarding the usage of DataAccess inside an ASP.NET application but my case is rather special because I use Visual Web Gui, which acts as WinForms inside the asp.net, so the only real possible solutions that I have are either disposing the context after any CRUD operation(and somehow don't use the objects that were maintained by that context either by using DTO template, or using detaching, in these cases I had some experiences in the past about performance penalty and are not option), or disposing the context after the form was closed, which brought me to the question that I asked in the beginning in my post.
So to summarizes this up I would like to know:
1.What is the correct way of disposing the context and without any memory leaks?
2.What is the best settings that I would have to make on the IIS part ,regarding application pool?
1 Answer, 1 is accepted
0
Hi Stelian,
Your observation are in the right direction. There is internal relation between the entities and the context instance that have retrieved them. This is in order to be able to manage their changes. In case your entities are still referenced it could happen than not all objects in the context instance will be disposed properly. The proper time to dispose a context instance would be when all entities are not reachable by your code. You already listed the possible solutions:
1. Use DTOs
2. Use Attach/Dettach
3. Use longer living contexts - you should somehow detect what is the proper time window based on your specifics. Probably you will need a context instance per user, per form, and you should handle unexpected page exits, like closing the entire browser.
It is up to you to select the most suitable solution based on the constraints you have.
If you are using the low level ADO API and the result is loaded in persistent classes, defined in the model, the situation is the same. Telerik Data Access will not create any internal relations between entities and the context in case the result is loaded in in custom classes, like the classes generated for the result shapes of a stored procedure. Such objects are only materialized by Data Access and meant to be read-only and thus the context instance doesn't manage them.
Regarding the ConnectionPool settings, it depends how loaded your site and your database will be. Even if your site is not heavily loaded, the databases server could be shared between multiple applications and some of them is consuming most of the available connections. You can control the number of connections to be created by the ConnectionPool settings in order to guarantee all applications will manage to work properly. Unfortunately there is no general advice for those settings, they are determined by the environment of the application.
I hope this helps. Should you have any additional questions do not hesitate to get back to us.
Regards,
Kaloyan Nikolov
Telerik
Your observation are in the right direction. There is internal relation between the entities and the context instance that have retrieved them. This is in order to be able to manage their changes. In case your entities are still referenced it could happen than not all objects in the context instance will be disposed properly. The proper time to dispose a context instance would be when all entities are not reachable by your code. You already listed the possible solutions:
1. Use DTOs
2. Use Attach/Dettach
3. Use longer living contexts - you should somehow detect what is the proper time window based on your specifics. Probably you will need a context instance per user, per form, and you should handle unexpected page exits, like closing the entire browser.
It is up to you to select the most suitable solution based on the constraints you have.
If you are using the low level ADO API and the result is loaded in persistent classes, defined in the model, the situation is the same. Telerik Data Access will not create any internal relations between entities and the context in case the result is loaded in in custom classes, like the classes generated for the result shapes of a stored procedure. Such objects are only materialized by Data Access and meant to be read-only and thus the context instance doesn't manage them.
Regarding the ConnectionPool settings, it depends how loaded your site and your database will be. Even if your site is not heavily loaded, the databases server could be shared between multiple applications and some of them is consuming most of the available connections. You can control the number of connections to be created by the ConnectionPool settings in order to guarantee all applications will manage to work properly. Unfortunately there is no general advice for those settings, they are determined by the environment of the application.
I hope this helps. Should you have any additional questions do not hesitate to get back to us.
Regards,
Kaloyan Nikolov
Telerik
OpenAccess ORM is now Telerik Data Access. For more information on the new names, please, check out the Telerik Product Map.