Re: Nested context on ROP proposal

From: Andrey Razumovsky (razumovsky.andre..mail.com)
Date: Fri Oct 24 2008 - 05:02:35 EDT

  • Next message: Kevin Menard: "Re: svn commit: r707569 - in /cayenne/main/trunk/framework/cayenne-jdk1.5-unpublished/src: main/java/org/apache/cayenne/ObjectContextStateLog.java test/java/org/apache/cayenne/remote/CayenneContextDeletionTest.java"

    >
    >
    > Would committing a nested context on the client cause a connection to be
    > made to the server and lifecycle events, validation run on the server for
    > objects in that context? If so, will changes which are made by lifecycle
    > events (eg. new objects created) be propagated to the client (which
    > currently doesn't happen) so they can be included in the parent context when
    > it is then committed?
    >
    > Or do they remain purely on the client until the parent context is
    > committed? In that case, what happens if the server validation fails for
    > objects in the child context?

    Nested context idea specifies that changes should be purely on the client.
    Otherwise we lose ability to commitChangesToParent()
    Client nested context is normal CayContext, just with another DataChannel,
    (i.e. source to commit changes to). So validation works *on client* within
    context which called commitChanges(). Changes to server (with server
    validation & lifecycles) will proceed through all context hierarchy if you
    call CayenneContext.commitChanges(),
    not CayenneContext.commitChangesToParent(). That's just the same as with
    DataContext, I haven't invented anything new.
    As you correctly pointed out, problem occurs with the following sequence:
    1. Nested CayContext [with incorrect changes] is committed to parent.
    Validation on nested client context succeeds
    2. Parent context is committed to server. Validation on client context
    succeeds since it did in #1
    3. Server validation fails. Parent context changes are rolled back.
    By default in nested context they do not.

    Right now I cannot think of ideal solution.
    At the minimum we could just do nothing and hope that server validation will
    succeed if client did.
    We could check objects before committing to parent (i.e. do 'false' commit
    to server), but I'm afraid that'll be too expensive.
    Or we could send notification to children if parent commit failed, but this
    is quite unnatural to make changes in child context behind the scenes.
    Would be great if we together thought about it

    Andrey



    This archive was generated by hypermail 2.0.0 : Fri Oct 24 2008 - 05:03:15 EDT