Documentation:CacheInvalidation

This is work in progress and not available for production

MDrivenCacheInvalidationAdmin

• LastInvallidationLoop
• LastUpdateLoop

MDrivenCacheInvalidationRecentlyUpdated

• id
• classname
• membername
• time

MDrivenCacheManifestHead

• ViewModel
• RootId
• Class
• viewmodelMetaChecksum // set on update
• priority // set by viewmodel property - this way information can control importance!
• AllowOldness // set by viewmodel property - this way information can control when
• Updated     // set on update
• Invalidated

MDrivenCacheManifestRow

• Id
• Class
• MemberName

Upon normal save

new rows indicating member level change are inserted in MDrivenCacheInvalidationRecentlyUpdated

Special treatment of newly created and deleted objects - they get the **created and **deleted flag

For changed embedded links (single end) we also add dirty of other end

Upon InvalidationLoop

we look for direct hits on id and attribute and invalidate

we look for any objects of class that has been changed recently that now should be part of the set

(ie other end of OptionalAssociationEndNameForBeingIncluded , does it point to id -> invalidate)

we look for manifest rows indicating use of allinstances and match to **created and **deleted and invalidate

we look for meta checksum change of viewmodel

Upon UpdateLoop

We look for Invalidated that has the diff between Now and Invalidated higher than allow oldness, we sort these by priority.

For each cache found we instansiate the named ViewModel with for the given root object.

We execute all actions on the ViewModel

We save all the used and hence dependant model usage during cache - allowing us to set persisted calculated fields and create persisted derived objects.

We ignore use of common super class members to avoid having caches be invalidate by un-precise things ie changetime

Things to think about

How do we ensure initial creating of cache - when a new cache is created that already have existing root objects?

Is the current polled criteria based SSVM-Run helpful? Is it the criteria based expression that discovers new cache needs or is it based on type alone?

Is the cache type-wise complete - or only on matching the polling criteria?

If we want to involve the polling criteria (ocl-ps) with creation need - do we also want it with refresh need?

- If we involve the polling criteria in refresh decision we may end up with a invalidated caches that never gets updated and that is not good.

- It may be easier for user to completly seperate the polled criteria ViewModels from the auto invalidated, mixing the two reasons for running may get confusing

Anyway we look at it - we need someway to join in the cachehead to make use of the invalidated value in order to select viewmodels to create/refresh