Child pages
  • EOF-Using EOF-Caching and Freshness

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3


The argument '2' up there is the number of seconds prior to the creation of the EOEditingContext, that that EOEditingContext is willing to accept data from. You can use whatever value you want. Thinking about it, you'll realize that setting it to '0' as you might initially want to, your app will potentially make very many more db transactions when under very heavy load, without gaining much in 'freshness' of data, so a non-zero value is probably preferable.

[WO:Oops, depending on which documentation you believe for which version, the argument may be in milliseconds instead of seconds. Beware].

[WO:in WO5.2.3 the default is 3600000 so obviously is milliseconds]


What Various Developers Actually Do

Andrew Lindesay

Here is a picture of bascially how an EOF stack might look. The EOEditingContext-s that are sharing the same EODatabase through an EOObjectStoreCoordinator will essentially be backed by the same set of snapshots and it is the snapshots that provide the data for the EOEnterpriseObject-s. There are "row" snapshots providing attributes and foreign/primary keys from an EOGlobalID as well as "to many" snapshots that provide an array of EOGlobalID-s that fulfil a "to many" relationship from a source EOGlobalID.

Image Removed

I was recently working on a change-notification system for my LEWOStuff framework and discovered some things about data freshness which I will outline here.

  • "Manual editing" of the raw snapshots
    • This seems very hard to get right and in fact I have not succeeded at this.
    • You need to lock the EOObjectStoreCoordinator involved as well as the EODatabaseContext before you make any changes to any snapshots or concurrency problems will arise.
    • You need to post a notification EOObjectStore.ObjectsChangedInStoreNotification if you do make any changes. If you do this, you need to include the arrays of changed EOGlobalID-s against the DeletedKey, InsertedKey and UpdatedKey.
  • Refetching the objects with "refreshes refetched objects" turned on and "prefetching relationship key paths" set.
    • This seems to update the attributes and foreign keys for the fetched objects.
    • This does not seem to update the to-many relationships for the fetched objects.
  • Invalidating the Objects by EOGlobalID in the EOEditingContext** This seems to initially effect only the EOEditingContext on which the invalidation was invoked.
    • This seems to cause an update to the attributes and foreign keys for the invalidated objects.
    • This seems to cause an update to the to-many relationships for the invalidated objects.
  • Invalidating the Objects by EOGlobalID on the EOObjectStoreCoordinator** This seems to effect all of the EOEditingContext-s using this EOObjectStoreCoordinator as their parent object store.
    • This seems to cause an update to the attributes and foreign keys for the invalidated objects.
    • This seems to cause an update to the to-many relationships for the invalidated objects.

For my change notification system, I eventually relied on the last approach here.

Jonathan Rochkind

In my own highly interactive and collaborative applications, I place a high value on freshness of data, over efficiency of my app. Implementing the setDefaultTimestampLag with a very low value, and calling setRefreshesRefetchedObjects(true) on the majority of fetches has resulted in acceptable and reasonably fresh data in my applications. I do not really think that the efficiency has suffered much either, but I haven't investigated it fully and I am not concerned with maximizing the number of requests-per-time-period that can be dispatched.


At WOWODC 2009 East, Mark Ritchie managed to dig up an old XCode project called Freshness Explorer for his demo. It appears the copy has been updated to work with WOLips and is currently located here (svn site) or it can be downloaded from here. That project has dependency on the MySQL database, which is great if you're using MySQL. If you are not using MySQL, you can use WO:this patch to remove the dependency and use Wonder's memory adaptor instead.