Re: Memory managment on EOF

On Aug 25, 2005, at 9:00 AM, Ricardo Strausz wrote:

> Hola a tod@s!
>
> I am facing the following problem:
> I have to move a database from one machine to other ---to be  
> precise, from Sybase 11.5 on Win NT, to Sybase 12 on OSX.
> Since the versions are not compatible, it is not possible via  
> standard backup.
> After trying some suggestions on the bible (aka PWO), with out  
> success, I decided to implement an app to do it ---the database is  
> huge!
>
> The basic idea behind the algorithm, is to traverse all entities in  
> the source-model and, for each one, traverse its data to create new  
> eos and insert them into the  sink-model.
>
> The problem: it is running out of memory!
>
> I already gave the JVM 1024Mb but it looks that it will run out of  
> memory sooner or later, no mater how many memory I assign to it...
>
> It cross to my mind that there should be a standard way to free the  
> used memory, say whenever a new entity is going to be traversed.
>
> What is better?
> 1. re-faulting.
> 2. using a new editing context for each entity.
> 3. creating a new store coordinator (for each entity)
>
> How to force to run the garbage-collector after releasing an store  
> coordinator?
> is it necessary?
>
> In five words: how to free system resources?

   There used to be an EOUtil that could do something like this. Does  
that still exists?

   Otherwise, it depends on how the ER relationship chart works. In  
our case, we have a set of objects that would more or less "own" all  
the other objects in the ER tree. So the code would look something  
like this:

   get master editing context

   fetch copies of all the master objects into the master ec (not  
that many, so ok)

   for each master object:

      make a local ec
      copy the master object into the local ec (localInstanceOfObject())
       do stuff with master object (i.e. copy them into the sink model)
      toss local ec

   Using the local EC is the key.

   If you have a large number of master objects enough that you can't  
load all of them into memory at once, then it gets trickier. One way  
is to just fetch a list of primary keys using raw rows, then use  
objectWithPrimaryKeyValue() to build the objects in the local editing  
context.

   If your ER tree is more complex (there is no "owner" object, then  
YMMV).

   Pierce