Each objectscope maintains a dictionary of object identity to in-memory objects, the type of the references can be configured and the default is to hold weak references. The dictionary is used to make sure that the objects in the objectscope are always unique. If a query returns an object that is already in memory the result will contain the object that is already there.
Keeping references to all objects that are loaded in the scope might consume a lot of memory. To avoid this OpenAccess references the loaded data with weak references.
Additionally the objectscope keeps strong references to all inserted, updated and deleted objects for as long as the transaction lasts.
In case of weak references, unreferenced instances are garbage collected very quickly. Weak references are useful for applications with generally short lived objectscopes and large heaps (e.g. web applications). Fewer objects on the heap will reduce garbage collection time. In case of "Strong" references, unreferenced instances are only garbage collected when they are manually evicted by the application or when the objectscope is closed. Strong references are useful for applications that always have short lived objectscopes (e.g. applications using the "one objectscope per request" model).
In case of strong references, all the objects are kept in memory as long as the objectscope is not disposed.
In case of bigger FetchPlans OpenAccess does not build up the complete object tree immediately. Sometimes this leads to GC runs before the application was able to navigate over the complete tree and data from the FetchPlan is already garbage collected. To avoid this OpenAccess has a special reference mode named ‘Auto’ that keeps the objects in the FetchPlan as strong references as long as the application has not touched it.
ObjectScope level cache modes:
||The GC might remove data if the application does not reference it|
||The GC is not able to remove data loaded in an objectscope|
||The GC is not able to remove FetchPlan data before the application has used it, but the GC can remove data that is no longer used by the application|
It is possible to configure strong and weak references as per your requirement, by adding the <pmCacheRefType> property to the <backendconfigurations> section in the App.config file as shown below:
<backendconfiguration id="mssqlConfiguration" backend="mssql">
By default, all clean and dirty objects move to the hollow state during the transaction's commit or rollback, unless the RetainValues or RestoreValues properties are set. This behavior ensures, that these object are fetched again from the database (or second level cache) if accessed in a subsequent transaction of the same objectscope. So these objects reflect an up-to-date view of the database content.
Due to performance reasons, it is sometimes desirable, not to re-fetch all the read objects as this might involve executing multiple client/server-calls.
To update these objects the method IObjectScope.Refresh(theObject) can be used, it fetches the current values from the database and refreshes the object's content.