... moving to devel list ...
On Jun 18, 2005, at 1:58 PM, Cris Daniluk wrote:
> mergeWithParent would first perform validateUncommittedObjects(), then
> proceed to re-register new/modified objects with the parent context.
It may not be that simple. There are concurrency issues of multiple
child contexts merging to the parent. So we need some strategy to
deal with merging changes to the same objects. Part of the solution
may be to use events to propagate any changes to all children... But
still some smart merging is needed.
> Discarding the DataContext needs addressed though...
How about implementing a stack of nested contexts bound to
ThreadLocal, with only one context accessible to the tread at any
given time. Once you commit the child to parent, child is discarded
and parent becomes the current thread context. Are there (m)any cases
when there is a need to access more than one context?
As for cleaning this up, child context will be garbage collected on
its own - I don't think there is a need to unregister anything... If
some other application objects hold on to this context DataObjects,
unregistering all objects is still a good thing to do, but won't
prevent problems resulting from application attempts to reference
objects that are "out of scope".
> I'd be happy to work on it if its not in conflict with the multi-
> tiered DataContext work, etc
The two features are complimentary and are being designed in
parallel. The method you will be looking to implement is
org.objectstyle.cayenne.service.ObjectDataContext.commitChangesInContext
(...). ObjectDataContext is where all the server-side extensions go
right now.
Andrus
This archive was generated by hypermail 2.0.0 : Sat Jun 18 2005 - 14:32:07 EDT