Quite some people have been wondering – why does the Telerik OpenAccess ORM team suggest using a separate object scope per every HttpRequest in a web scenario or on a thread level in desktop apps. Doesn’t this lead to many set-backs? What happens with change-tracking, optimizing the DAL using cache, synchronization..
This post will be dedicated to explaining why the per-request approach is not only the better, but the obligatory one in most of the cases.
Usually data-modifications are transaction-bound in 99% of the cases. When the scenario does not allow that e.g. we need several requests to do a single update, there is the Object Container that can always come in handy. There is a blogpost posted few weeks ago on handling Multipage update cases which can be used as a reference.
There have been some arguments on optimization and using the cache. This is the ideal scenario where the 2nd level cache shows its full potential. The 2nd level cache is shared by all object scopes that are related to a specific database. That said Telerik OpenAccess ORM still optimizes the database access using cached objects as well as compiled queries.
Concurrency also is always a concern. How do we synchronize multiple scopes in optimistic concurrency fashion? It is automatically done by the runtime of Telerik OpenAccess ORM in desktop scenarios. For the web one can easily take over the control and customize his/her own concurrency handling. The topic has been discussed in our team blog before as well.
If I was asked, the biggest reason to not using the shared object scope on application level is that it is not a completely synchronized object by itself. Nested transactions are one obstacle that a shared scope can lead to. Imagine the following sample scenario: there is a Person object bound to a single scope and one thread starts modifying it. Before calling scope.Transaction.Commit() another thread requested the same object for editing and starts a new transaction. Here you bomb with a nested transaction exception. Even if you have scope.TransactionProperties.AutomaticBegin turned on, you are still having an Optimistic Concurrency problem without anyone hitting the database!
I hope this post helps those that are rather new to OpenAccess or just having trouble understanding how it operates in real-life scenarios.
Subscribe to be the first to get our expert-written articles and tutorials for developers!