I found code, which uses MagmaOidManager in two different processes. I placed a check instead of Mutex in it, which throws error, if some other process instead of one, which was first who accessed it tries to deal with oids.
After running update, i found, that the only process, which accessing oid manager except one, which running update is running by magma itself:
See fork in MaObjectRepository>>flushCacheSoon.
After changing this method to:
flushCacheSoon self flushCritical: [ self commitCritical: [ self flushCache. applyProcess _ nil ] ]
there's no other processes who attempt to use oid manager from except one, which runs update.
So, the conclusion is obvious: flush causing problems.
Cris, please check the #flushCritical: code. I think it should not run inside a commit or parallel to commits if we want it to run it in standalone process. Otherwise magma disregards own rule which says that following is not allowed: session commit: [ [ some code ] fork ]
Also, i'm glad to note, that with changes in #flushCacheSoon, Florian able to run own update without errors regardless using my dictionaries or using stock classes.
But timing are different: - out of the box magma: 18 minutes - using my dictionaries: 8 minutes.
quite impressive for real world application isn't? :)
Cris, in attachment i placed the MagmaOidManager code, which checks the process. Just for case, if you want to see it yourself.