[ANN] Magma 1.0r40
Igor Stasenko
siguctua at gmail.com
Thu Sep 27 19:25:11 UTC 2007
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.
--
Best regards,
Igor Stasenko AKA sig.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MagmaOidManager.st
Type: application/octet-stream
Size: 3877 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/magma/attachments/20070927/39bbcf54/MagmaOidManager.obj
More information about the Magma
mailing list