This should work. I often use "peer" DataContexts as a workaround too.
> The big difference so far is that a commit would go to the database
> and not to the parent DataContext. However, I think even that could be
> easily addressed with some cleverness, by registering the changed
> objects with the parent DataContext and then discarding the child
> DataContext.
That would be an implementation of the nested DataContext feature ;-)
Andrus
On Jun 17, 2005, at 8:18 PM, Cris Daniluk wrote:
> In lieu of nested DataContexts (which I for one can't wait for!), I
> thought of an interesting workaround and wanted to see if I'm
> overlooking any potential pitfalls.
>
> I've created a ThreadLocal object that holds the DataContext, rather
> than using the built-in ThreadLocal. A user can either request a
> "parent" DataContext, which will return the DataContext encapsulated
> by the ThreadLocal, or retrieve a "child" DataContext, keyed by some
> form of token and wrapped in some form of proxy. This DataContext
> would again be apart of the ThreadLocal, but would not be party to
> other operations which the user may have in progress. The user could
> perpetually retrieve the DataContext until invoking a commit, at which
> point the proxy would gracefully eliminate that DataContext. This
> gives a possible point of access to reconcile any changes to the
> object graph back into the parent.
>
> The big difference so far is that a commit would go to the database
> and not to the parent DataContext. However, I think even that could be
> easily addressed with some cleverness, by registering the changed
> objects with the parent DataContext and then discarding the child
> DataContext.
>
> Anything missing?
>
> Cris
>
>
This archive was generated by hypermail 2.0.0 : Sat Jun 18 2005 - 13:39:53 EDT