Great responses and I'm getting some ideas.... Here's some more details:
Here's a simplistic view of how my process should work:
1. Wait for work a request to arrive
2. Read the EOs needed to process the work request
3. Perform calculations for the work request
4. Save changes
5. Invalidate the application's EO cache
6. Go back to #1.
I just create an editing context the normal way, e.g. ec = new EOEditingContext();
This editing context is used through out all these steps (1 thru 6).
The EOs needed to process the work request and perform the calculations are read into this editing context. I then save the results and the work request with its complete flag set.
The EOs read in step #2 are basically a very deep graph of EOs, with a lot of to-many and to-ones relationships and like I said, it's deep ;-) You can think of these objects as the parameters used for the calculations in step #3. These EOs will not change while the work request is in-progress.
Once the calculations are performed and changes are saved to the database I would like to clear the cache. The reason is that I go back to #1 to wait for another work request. But the new work request may reference the same EOs from a previous work request. And the EOs may have been modified in a web application where a user can edit the parameters in those EOs and submit a new work request.
I'm still not sure which way to go to invalidate the object cache. Invalidating EOs in object graph would be an option except that the graph is so deep and it may change over time. For example, new relationships may get added to the object model, etc. So the code I write to invalidate the object graph may not be accurate a few weeks from today. :-)
I'm leaning towards EOEditingContext's dispose(). Not sure what it will do exactly though. I guess I will have to run some tests to give it a shot.
This should work fine for your situation. I do the exact same thing - servers run for weeks/months and never increase RAM, and I always get fresh objects because disposing of the EC causes the snapshots to go away, so they get read in again at the next request.
I found this but like I said I'm still not sure which way to go:
Let me know if you have some ideas what would be best for my application.
Thanks to all who have responded.
Ricardo Parada
On ago 3, 2006, at 11:36 AM, Ken Anderson wrote:
On Aug 3, 2006, at 12:21 PM, Ricardo Parada wrote:
If I create an editing context, then read some EOs into memory. Then I throw away the editing context by assigning null to the variable referencing the editing context.
Then I create a new editing context and read the same EOs into memory. Will the EOs have the same data as the ones read into memory when I created the first editing context?
Did you save the first editing context before nulling it? Was it a child or peer editing context? Did you also remove any references to the original EOs ?
Anyways, I guess what I'm looking for is an effective way to read in some EOs into memory, perform some work, save the changes and then clear the application's object cache and start over. This is not a web app. It is a background process that does some analysis. So every time I read my
EOs the entire object graph has to have fresh data from the database.
In general, it's not a problem to fetch some EOs, do some work, save, then start all over again with a new EC. As Gavin has pointed out, use counting of snapshots actually works now, so in your scenario, there's no reason to invalidate objects. If something outside of your app is going to modify the rows, you might want to change the default lag using setDefaultFetchTimestampLag on the editing context (it defaults to an hour I believe).
Is this the right way to do this:
EOEditingContext.rootObjectStore().invalidateAllObjects();
Thanks
Ricardo Parada
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
