Re: Best Strategy for Cacheing
Re: Best Strategy for Cacheing
- Subject: Re: Best Strategy for Cacheing
- From: David Avendasora <email@hidden>
- Date: Thu, 30 Oct 2008 05:13:52 -0400
On Oct 23, 2008, at 6:36 PM, Oliver Scheel wrote:
Am 23.10.2008 um 12:21 schrieb David Avendasora:
places. But now that I'm moving to using multiple ECs instead of
the default EC so I'm going to have to do the work of compiling the
list of Components for each EC instead of once per session.
What is your motivation to use multiple ECs in this case?
Because I was running into problems where the saveChanges() was
generating errors stating that required toOne and toMany relationships
were null and others were pointing to objects that weren't in the DB
any longer. I couldn't figure out what process was causing them so I
figured moving away from the defaultEditingContext would at least help
narrow things down. Turns out some of the delete rules on my Model had
changed to "Do Nothing" or "Nullify" instead of "Cascade" so objects
were hanging around that should have been deleted, and some of them
pointing to other objects that had been deleted.
Another question: How many objects are created (in terms of 10^x)
10^3+
Initially, it's not a huge amount, several hundred for each
routing(). The problem is that it is entirely possible to be asking
for the Components of a few thousand Routings in a given request.
Therefor be generating tens of thousands of Components or more.
and must the object graph be created in one process?
I'm not sure what you mean by one process.
And last but not least: Which database do you use?
Microsoft SQL Server. (yeah, I know)
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden