Hello;

I thought a follow-up might be worthwhile in case anybody is searching the list following this thread and to see if I'm doing anything silly... Basically I solved this one by using the snapshots to find;

a) the presence of the row-caches in the co-operating object stores
b) the present to the to-many caches in the co-operating object stores

This process identifies the row-caches and to-many caches that need to be modified to reflect the changes in the data made in another instance.

What I was then doing was to fiddle the snapshots to update them to be current based on data that I was shifting around in a change- notification message from the changing instance. This was difficult, messy and prone to error. Based on advice, I then accepted that I would just simply refetch causing database traffic, but less complexity.

I tried to fresh-fetch those EO's based on which ones appeared to have row-caches in the target co-operating object stores, but despite using prefetching, the to-many snapshots were left untouched! So it worked for the to-one relationships and for simple attributes, but not for to-many's.

The next thing I learnt was that if you invalidate some GID-s in an editing context then the data is not refreshed in sibling EC's until some later time (which I won't go into), but if you invalidate the GID-s on the object store co-ordinator then the changes are immediately propagated up into the coordinated EC-s straight away and this seems to finally result in a complete refresh of everything about the stale EO.

cheers.

Thanks for the advice Mike -- I'll follow up on that early next week and see if I can resolve this issue.

You say below you're calling "forgetSnapshotForGlobalID(...)".  Under
what circumstances?  That would likely cause this ... If you have

___
Andrew Lindesay
technology : www.lindesay.co.nz
business : www.silvereye.co.nz


_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

Reply via email to