Does this have any bearing on your problem?

    /**
* Clears snapshot the relaationship of a given enterprise so it will be read again when next accessed.
     * @param eo enterprise object
     * @param relationshipName relationship name
     */
public static void clearSnapshotForRelationshipNamed(EOEnterpriseObject eo, String relationshipName) {
        EOEditingContext ec = eo.editingContext();
        EOModel model = EOUtilities.entityForObject(ec, eo).model();
        EOGlobalID gid = ec.globalIDForObject(eo);
EODatabaseContext dbc = EODatabaseContext.registeredDatabaseContextForModel(model, ec);
        EODatabase database = dbc.database();
ERXEOControlUtilities.clearSnapshotForRelationshipNamedInDatabase(eo, relationshipName, database);
    }

That is what I use to re-fresh to-many relationships. The only time I use invalidate is when I know that an EO with a snapshot has been deleted from the database.


Chuck

On May 20, 2010, at 3:53 PM, Andrew Lindesay wrote:

Hello Mike;

I think I was _just_ doing fetches at one point, but I suspect that there was a change in 5.3 -> 5.4 in that "invalidate...()" in 5.3 did not drop to-manys from caches in EOF and 5.4 seemed to. In 5.3 fresh fetch with pre-pretches into to-manys did re-cache the to- many, but in 5.4 it did not seem to. I obviously am unable to look and see what it is actually doing, but that is my observation and the only way I could get it to function for to-many's is to use invalidate... –– I presume that change notification in PW is functioning seamlessly under high load in 5.4 without invalidate and for to-many relationships? Do you take out a DBC lock for the duration of the change notification process for all DBC's which are involved in the changes? I guess I should go take a look...

cheers.

What I have done is to use a lock across the work of handling R-R cycles and the change notification (the only place where the invalidate is actioned). In this way, if the issue is one of concurrency with "regular EC use" then I should see this issue go away for human-facing instances which are doing any EC-work outside of the R-R cycles. It's still a fair way off a production deploy, but I will let you know if this resolves the issue.
in wonder's we take a dbc lock during the background queue processing, then do a refreshing fetch of the affected EO so that it updated the snapshots. you really don't want to ever do an .invalidate() because if you any EO's in an modified state, they'll be messed up.

___
Andrew Lindesay
www.silvereye.co.nz

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net

This email sent to ch...@global-village.net

--
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects







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

This email sent to arch...@mail-archive.com

Reply via email to