Without a specific use case, it's hard to comment on how you can do
things better.
If your read-only objects are independent of your modified objects,
you can use separate data contexts for them. If they're
interdependent, then you have to keep around references to them in any
case in order to maintain the object graph.
On 9/6/05, Gili <cowwo..bs.darktech.org> wrote:
>
> Yes, but if the DataContext consists of a mix of read-only and modified
> objects then this is not an object. Ideally I should be able to discard
> the read-only objects while keeping the modified ones around. I really
> wish we could do something like a SoftReference but for the read-only
> cache; I just can't think up of how to do this. It would be great to
> next have to flush the cache or run out of memory unless you actually
> *wrote* a lot of changes.
>
> Gili
>
> Mike Kienenberger wrote:
> > Normally, if you're trying to deal with large data sets, the
> > recommended solution is to dispose of your datacontext after every so
> > many operations and start over.
> >
> > On 9/6/05, Gili <cowwo..bs.darktech.org> wrote:
> >
> >> invalidateObjects() seems to be used for faulting objects so that they
> >>are refreshed from the DB next time they are hit. unregisterObjects()
> >>seems to be used for preventing read-only objects from triggering an
> >>OutOfMemoryErrors. Am I correct?
> >>
> >>Gili
> >>--
> >>http://www.desktopbeautifier.com/
> >>
> >
> >
>
> --
> http://www.desktopbeautifier.com/
>
This archive was generated by hypermail 2.0.0 : Tue Sep 06 2005 - 11:20:13 EDT