• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Managing EOF caching
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Managing EOF caching


  • Subject: RE: Managing EOF caching
  • From: Dave Rathnow <email@hidden>
  • Date: Wed, 18 Jan 2006 10:56:46 -0700

Is there a difference in the way EOF caches an object if it is fetched using an EOFetchSpecification or if it is retrieved by traversing a relationship?  If I do a bulk fetch using a fetchSpec and then access these object via a relationship from a related object, will EOF use the cached object or fetch it from the database?
 
Thanks,
Dave.
-----Original Message-----
From: Ken Anderson [mailto:email@hidden]
Sent: January 18, 2006 08:29 AM
To: Dave Rathnow
Cc: 'email@hidden'
Subject: Re: Managing EOF caching

Dave,

What you're doing is OK, and pretty typical (at least for me).  I try to limit the destruction of snapshots to the destruction of an editing context, so I don't have objects lying around that are not garbage collected, but their snapshots have been removed from the database context.

In one situation, I would have a singleton manage the 'ref data' context (which stored often used reference data).  When a 'transaction' editing context was destroyed, it would invalidated all the EOs in THAT editing context that did not have a companion in the ref editing context (managed by the singleton).  In that manner, we would hold on to ref data indefinitely, but only hold on to transactional data for the life of the context.

Ken

On Jan 17, 2006, at 12:07 PM, Dave Rathnow wrote:


We have an application that processes well data that is reported at regular and irregular
reporting periods.  The bulk of the data arrives in the morning within a two hour window.  The
application is headless, that is, it has no UI.

When we first wrote the program we were having problems with running out of memory and
the simplest solution we found was to periodically dispose of the editing context and then
nuke all snapshots from the EODatabase object.   This solved the memory problems but of
course we lost the advantage of any EOF caching.  Unfortunately, we are now at a point where
we are falling too far behind during busy periods so we have to revisit the problem and find
a better solution.

This application is one part of a bigger system and it's primary job is to process incoming data
according to a set of business rule.  The processing involves fectching object from the DB and
creating other objects that are then stored in the DB and consumed by other applications in the
system.   Most of the fetched objects should stay in memory since they will likely be used in the
future to process data from the same location.  Other objects could probably be nuked after a
period of time.  The newly created objects are not required and could be released as soon as they
are saved to the DB.

I've been playing around with different optimization strategies including batch fetching but the one
that seems to work the best is to save all inserted objects in my EC before I call saveChanges and
then nuke the snapshots from the EODatabase after the saveChanges has finished.  My overall memory
requirements have increased but they seem to level out at an acceptable level.

So here are my question:

1. Does anyone have some ideas how to handle this type of caching requirements?  Is there
another/better approach or different solution?

2. Assuming what I'm doing is an acceptable approach, can I control how long objects are cached
by EOF and what objects are cached?

3.  Does nuking snapshots in the way I'm doing it have an bad side effects.

Thanks,
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

 _______________________________________________
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

  • Follow-Ups:
    • Re: Managing EOF caching
      • From: Ken Anderson <email@hidden>
  • Prev by Date: Re: Managing EOF caching
  • Next by Date: Re: Managing EOF caching
  • Previous by thread: Re: Managing EOF caching
  • Next by thread: Re: Managing EOF caching
  • Index(es):
    • Date
    • Thread