This question is locked. New answers and comments are not allowed.
Wanted to know why do we require "Refresh(RefreshMode.OverwriteChangesFromStore, Entities.Entity)", if we are already creating new "EntitiesModel" and performing operations with in that scope.Can you please explain how does it make difference.
3 Answers, 1 is accepted
0
Hi venkata,
Generally, the context.Refresh is intended to refresh an object that gave you an OptimisticVerificationException as described in this documentation article. You should have in mind though that calling the Refresh method will result in multiple database calls - at least one query per item that needs to be refreshed. So using it with large collection of objects will most likely lead to performance issues.
Could you please give us a bit more information on your implementation scenario so we could advice you better? Is your goal to decide on the life-cycle of a context - whether to use a long living or a short living context? Do you have a web application or a desktop one?
Generally speaking out recommendation is to use short living context nevertheless this is a design decision you have make based on you implementation scenario and requirements. Short living contexts does not hold opened connections, they allow better transaction management as less operations will be executed from the same instance. Short living context are the recommended approach in multi threaded scenarios - this would prevent one thread pushing changes that are mode by another thread.
On the other hand, a long living context has a richer level one cache (this could also be a reason for higher memory consumption).
I hope this is helpful. Do not hesitate to contact us back with any further questions.
Regards,
Boyan
Telerik
Generally, the context.Refresh is intended to refresh an object that gave you an OptimisticVerificationException as described in this documentation article. You should have in mind though that calling the Refresh method will result in multiple database calls - at least one query per item that needs to be refreshed. So using it with large collection of objects will most likely lead to performance issues.
Could you please give us a bit more information on your implementation scenario so we could advice you better? Is your goal to decide on the life-cycle of a context - whether to use a long living or a short living context? Do you have a web application or a desktop one?
Generally speaking out recommendation is to use short living context nevertheless this is a design decision you have make based on you implementation scenario and requirements. Short living contexts does not hold opened connections, they allow better transaction management as less operations will be executed from the same instance. Short living context are the recommended approach in multi threaded scenarios - this would prevent one thread pushing changes that are mode by another thread.
On the other hand, a long living context has a richer level one cache (this could also be a reason for higher memory consumption).
I hope this is helpful. Do not hesitate to contact us back with any further questions.
Regards,
Boyan
Telerik
Check out the latest announcement about Telerik Data Access vNext as a powerful framework able to solve core development problems.
0
venkata
Top achievements
Rank 1
Rank 1
answered on 22 Jun 2015, 08:42 AM
Thanks for your Reply.
We have a scenario where multiple threads operate on single entity i.e. basically multiple threads doing CRUD operations on single entity.So we need to make sure we have always updated copy in the context to perform any CRUD operation, to achieve this Refresh entity has been triggered, which is also causing a performance issue.So how do we make sure the Entity which is loaded in the context is always an updated or recent copy before performing any CRUD operation.
0
Hi venkata,
Is a single entity refreshed or a collection of entities? If its a collection then as mentioned multiple database calls are going to be executed. In such situations, it could be cheaper to retrieve the entire data again in a single database pass rather then invoking a refresh operation.
The recommended approach in such situations (when using optimistic concurrency management) is to directly try to update the entity. If the SaveChanges() call produce an exception then the entity must be re-retrieved from the database (possible using the Refresh method) and the update operation must be retried only in case that it is still feasible. This documentation article demonstrates the described approach.
Let us know if you need any further assistance.
Regards,
Boyan
Telerik
Is a single entity refreshed or a collection of entities? If its a collection then as mentioned multiple database calls are going to be executed. In such situations, it could be cheaper to retrieve the entire data again in a single database pass rather then invoking a refresh operation.
The recommended approach in such situations (when using optimistic concurrency management) is to directly try to update the entity. If the SaveChanges() call produce an exception then the entity must be re-retrieved from the database (possible using the Refresh method) and the update operation must be retried only in case that it is still feasible. This documentation article demonstrates the described approach.
Let us know if you need any further assistance.
Regards,
Boyan
Telerik
Check out the latest announcement about Telerik Data Access vNext as a powerful framework able to solve core development problems.