EOObjectStoreCoordinator overrides the following EOObjectStore methods:
With the exception of saveChangesInEditingContext, EOObjectStoreCoordinator's implementation of these methods simply forwards the message to an EOCooperatingObjectStore or stores. The message invalidateAllObjects is forwarded to all of a coordinator's cooperating stores. The rest of the messages are forwarded to the appropriate store based on which store responds true to the messages ownsGlobalID, ownsObject, and handlesFetchSpecification (which message is used depends on the context). The EOObjectStore methods listed above aren't documented in this class specification (except for saveChangesInEditingContext) for descriptions of them, the EOObjectStore and EODatabaseContext (EOAccess) class specifications can be referred to.
For the method saveChangesInEditingContext, the coordinator guides its cooperating stores through a multi pass save protocol in which each cooperating store saves its own changes and forwards remaining changes to the other of the coordinator's stores. For example, if in its recordChangesInEditingContext method one cooperating store notices the removal of an object from an"owning" relationship but that object belongs to another cooperating store, it informs the other store by sending the coordinator a forwardUpdateForObject message.
Although it manages objects from multiple repositories, EOObjectStoreCoordinator doesn't absolutely guarantee consistent updates when saving changes across object stores. If the application requires guaranteed distributed transactions, you can either provide his own solution by creating a subclass of EOObjectStoreCoordinator that integrates with a TP monitor, use a database server with built in distributed transaction support, or design the application to write to only one object store per save operation (though it may read from multiple object stores).