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
