Thank you for the detailed explanation.
I believe you should be concerned only with invalidation of Level 2 cache
and not the object data inside the OpenAccessContext
instance(s) itself (as we call it Level 1 Cache
We have deliberately prohibited the API that you want to use because of the complexity of possible scenarios and associations between objects in the context level data container.
In general any changes pending on context level over objects that are modified or deleted from another context/application are subject of concurrency control. You can check this article
how to set up concurrency control on entity type level and here
you can see how to handle concurrency conflicts when saving data.
For scenarios where you need the latest fresh data from the database my suggestion is to always use a fresh instance of your OpenAccessContext
class to perform a query. After disposing the context instance the associated Level 1 Cache
container will be destroyed and this way won't require remote invalidation.
Please note that the whole setup described above assumes that you are using short-living OpenAccessContext
instances that are used to perform single business operation and are destroyed after it. If you are using singleton or another form of long-living/shared context instance my suggestion is to evaluate if you can move to short-living pattern because it has plenty of inherent benefits and allows you to avoid issues like committing half-baked data due to shared transaction control or locking in multi-threaded scenarios.
OpenAccess ORM is now Telerik Data Access
. For more information on the new names, please, check out the Telerik Product Map