What to do with a MagmaCommitError

[Hernán Morales Durand]

2009/6/3 Chris Muller <asqueaker at gmail.com>

> Thanks for the great questions.
>
> > Now I have a Debugger with a MagmaCommitError. As you can see from the
> > attachement, the User2 session still has a transaction,
>
> The attachment shows the "transactionLevel" as 0, meaning the session
> is not in a transaction.  The 'transaction' instance variable always
> has a MaTransaction instance which is just a single per session to
> manage the readSet (for changed-detection).  It is completely private.
>
> so I have some
> > questions:
> >
> > -Is this transaction invalid in some way? I've observed some possibly
> > relevant protocol here (#restore? #changedObjects?)
>
> MaTransaction is completely private.  Access with caution.
>
> > -Supposing that it's appropiate to reapply User2 changes, do I have the
> > chance to do it from the Debugger?
>
> Magma guards its internal state, you may restart at the point your
> application issued the #commit, but be sure to check the session
> transactionLevel, you may need to manually send #begin to the session
> first if the application code doesn't..
>
> Likewise, if your application issued #commit: [ ... ]  and your
> session is at transactionLevel 0, then of course you can just restart
> from there..


Thanks for the explanations Chris. I tried to restart but the commitNumber
of the session in the debugger was nil, and when the session wanted to
reconnect and validate in #validateCommitNumber another MNU was raised. This
is expected for this kind of situation?


>
>
> > -If the Debugger isn't useful at this stage, how to apply the User2
> changes?
>
> A session that experiences a commit-conflict is no longer in a
> transaction, but the local changes can still be committed.  However,
> the state of the local model is now "merged" with updates from other
> users.  The MagmaCommitConflictError (Exception) has a
> MaFailedCommitResult, which has a collection of the objects that, in
> particular, the application may wish to review, they are the ones
> User2 changes now overlay the local changes.


>
> If the application wishes to continue committing the local changes, it
> may issue a #begin followed by a commit.  I must admit, it seems
> unnecessary to require the application to do this..  I don't think
> that would be difficult, hmm..
>
> Or, the application may issue an #abort to cancel all local changes,
> refresh all contents from the repository and start over.
>
>  - Chris
>


Hernan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/magma/attachments/20090604/cc0aeb51/attachment.htm