Am 29.03.2006 um 06:53 schrieb Chris Muller:
What if another session modifies something while a commit is in progress? Could this lead to problems? I guarded the commitAndBegin in a mutex, though.
I'm afraid so. If the model changes while its being serialized the serialized graph emitted from the serializer will not be a time-coherent representation of the model. It could actually have an invalid oid reference in the commit-package and Magma will signal a commit error.
Regrettably, I don't think a mutex only around commitAndBegin will guarantee safety under the shared-model approach. You said you were single user, so it should be fine. You could even get lucky with multiple users if no one changed the same parts of the model.
Could I somehow cancel the commitAndBegin? Like, using WriteBarrier I should be able to detect immediately if the model was changed while committing.
Or, another possibility, let the write barrier use the same mutex like my commitAndBegin. Thus, while it is committing, every write access of another thread would block until the commit is over.
But without lower-level synchronization built into the language, this is living dangerously. Wrapping the commit in a #valueUninterruptably or #valueUnpreemptively might actually help, crazy stuff though.
That sounds easiest, if it works, yes.
When each Seaside session has its own copy of the model, multiple processes are not an issue, and Magma sees them as independent clients so the concurrency detection works too. It is the only approach with potential to scale to multi-machines / processes as described on the Magma Seaside page.
Understood, but I'm still trying to avoid a complete SqueakSource rewrite.
- Bert -