r42Gamma3 was: What to do with a MagmaCommitError

[Hernán Morales Durand]

  Chris, we've updated yesterday to the latest Magma in our production
release and everything works great. The response time is much better!!
We had only one issue with an expected MagmaTruncationWarning
exception not returning control to the Debugger, after hitting the
Alt+. another Debugger appears stopped in a critical code section.
Cheers,

Hernan

2009/6/7 Chris Muller <asqueaker at gmail.com>:
>> 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?
>
> Thanks for the report  Hernán, you certainly know how to find the
> bugs!  Indeed, the recent addition of the commitNumber to the
> CommitResult did not get included in a FailedCommitResult, causing a
> session which then disconnected before crossing another transaction
> boundary, without its commitNumber, resulting in the error you saw
> upon attempting to reconnect that session.  Good catch!
>
> I have fixed this and release it as r42Gamma3.
>
> While I was in there, I decided to include a nice improvement to
> commit-conflict resolution.  Recall when you get a commit-conflict,
> you have access to #conflictingObjects.  Before, in r42Gamma2 and
> earlier, it just answered the conflicting objects but now it answers a
> collection of Associations whose keys are the original persistent
> object in conflict, and whose values are a shallowCopy of the local
> sessions version of that object before it was updated due to crossing
> the transaction boundary (the commit attempt).
>        This would allow a general commit-error handling user-interface that
> can present the conflicting objects side-by-side, maximizing
> reconciliation productivity.
>
> Very likely, not many applications even take advantage of
> #conflictingObjects, so no code changes will be necessary for most
> applications.  But applications which were making use of
> #conflictingObjects in r42Gamma2 or earlier will need to account for
> the richer model now in r42Gamma3.
>
>  - Chris
>
>
> On Thu, Jun 4, 2009 at 1:42 AM, Hernán Morales Durand
> <hernan.morales at gmail.com> wrote:
>>
>>
>> 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
>>
>> _______________________________________________
>> Magma mailing list
>> Magma at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/magma
>>
>>
>