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..
-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