The page http://wiki.squeak.org/squeak/2636 says:
"Thankfully, Magma will detect this conflict and signal a MagmaCommitError back to user 2. This is because she tried to change an object that was changed by User 1 since she began her transaction, invalidating her changes. The failed result object has the challenging objects that were in conflict (Object A) and the name of each user who changed them (User 1). Additionally, User 2 can now see the new Object A, as changed by User 1, because her commit attempt caused a crossing of a transaction boundary.
At this point, User 2 no longer has a transaction. She must reapply her changes under a new transaction, if appropriate. "
Now I have a Debugger with a MagmaCommitError. As you can see from the attachement, the User2 session still has a transaction, so I have some questions:
-Is this transaction invalid in some way? I've observed some possibly relevant protocol here (#restore? #changedObjects?)
-Supposing that it's appropiate to reapply User2 changes, do I have the chance to do it from the Debugger?
-If the Debugger isn't useful at this stage, how to apply the User2 changes?
Cheers,
Hernan
The page http://wiki.squeak.org/squeak/2636 says:
"Thankfully, Magma will detect this conflict and signal a MagmaCommitError back to user 2. This is because she tried to change an object that was changed by User 1 since she began her transaction, invalidating her changes. The failed result object has the challenging objects that were in conflict (Object A) and the name of each user who changed them (User 1). Additionally, User 2 can now see the new Object A, as changed by User 1, because her commit attempt caused a crossing of a transaction boundary.
At this point, User 2 no longer has a transaction. She must reapply her changes under a new transaction, if appropriate. "
Now I have a Debugger with a MagmaCommitError. As you can see from the attachement, the User2 session still has a transaction, so I have some questions:
-Is this transaction invalid in some way? I've observed some possibly relevant protocol here (#restore? #changedObjects?)
-Supposing that it's appropiate to reapply User2 changes, do I have the chance to do it from the Debugger?
-If the Debugger isn't useful at this stage, how to apply the User2 changes?
Cheers,
Hernan
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
To clarify two points:
If the application wishes to continue committing the local changes, it
If the application wishes to continue committing the *other* local changes, ... The ones that were not in conflict.
may issue a #begin followed by a commit. I must admit, it seems unnecessary to require the application to do this..
seems unnecessary to require the application to do *another begin*.. It should be left in a transaction that can be just committed or aborted.
Legacy commit-error handling may have to be updated, but probably not.. Opinions?
2009/6/3 Chris Muller asqueaker@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@lists.squeakfoundation.org
-
Chris Muller -
Hernán Morales Durand