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@gmail.com wrote:
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 mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
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@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@gmail.com wrote:
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 mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org
-
Chris Muller -
Hernán Morales Durand