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 : Fri Jun 17 2005 - 20:18:44 EDT